PHP2Shell: Two Critical PHP Vulnerabilities Allow Unauthenticated Remote Code Execution

The PHP development team has released emergency security updates addressing two critical vulnerabilities that could allow unauthenticated attackers to achieve remote code execution (RCE) on vulnerable web servers.

Tracked as CVE-2026-109618 and CVE-2026-109619, the vulnerabilities are collectively known as PHP2Shell. Both flaws affect memory management in PHP's core engine and have received a CVSS 4.0 score of 9.2 (Critical).

The vulnerabilities affect multiple supported PHP branches, including PHP 8.2, 8.3, 8.4, and 8.5. Security researchers have demonstrated unauthenticated code execution against Apache deployments using mod_php, making immediate patching a priority.

Affected PHP Versions

The PHP project has released security fixes for all affected supported branches.

PHP 8.1 and earlier versions are no longer officially supported by the PHP project. Organizations still using these versions should verify whether their operating system vendor provides backported security fixes or migrate to a supported release.

Technical Analysis of PHP2Shell Vulnerabilities

Researchers from Wiz Research, OpenAI Codex Security, and Calif identified two critical vulnerability classes affecting PHP's memory handling and request lifecycle.

Although both vulnerabilities involve memory safety, they arise from different underlying conditions.

CVE-2026-109618: Out-of-Memory Handling Leads to Remote Code Execution

CVE: CVE-2026-109618
Severity: Critical
CVSS 4.0: 9.2
Impact: Unauthenticated Remote Code Execution

The first vulnerability originates from PHP's handling of out-of-memory conditions during HTTP request processing.

Previously, PHP used the longjmp() mechanism to abruptly exit an operation when memory allocation failed.

Under certain conditions, this behavior could interrupt request processing before internal structures were fully initialized.

During subsequent request shutdown operations, PHP could access invalid or partially initialized memory, potentially creating conditions for arbitrary code execution.

Attack Conditions

The PHP security advisory identifies several request characteristics that can trigger excessive memory consumption:

• Multipart form submissions containing unusually large numbers of headers.
• Numerous empty file-upload fields that still require metadata allocation.
• Deeply nested form field names.
• Multipart requests without a usable content length.
• Requests that bypass initial size checks but continue consuming memory during parsing.

These conditions can cause PHP to exhaust available memory while processing attacker-controlled HTTP requests.

Apache mod_php Exploitation

Researchers successfully demonstrated unauthenticated remote code execution against Apache servers using mod_php.

The exploit was validated with default PHP input and memory limits.

Importantly, the vulnerable condition can occur before application-level PHP code begins executing.

This means application authentication and input validation may not prevent exploitation of the underlying PHP engine vulnerability.

For PHP-FPM deployments, researchers identified potentially vulnerable code paths through source analysis, although the same complete exploit was not demonstrated for that configuration.

CVE-2026-109619: Stale Global State and Use-After-Free Conditions

CVE: CVE-2026-109619
Severity: Critical
CVSS 4.0: 9.2
Impact: Memory Corruption and Potential Remote Code Execution

The second vulnerability affects how PHP manages global state across multiple HTTP requests handled by long-running worker processes.

In certain circumstances, a PHP worker can retain a reference to memory that has already been released.

If an error interrupts normal cleanup, a subsequent request handled by the same worker may access this stale reference.

This creates a potential use-after-free condition.

Confirmed Vulnerable Scenarios

The PHP advisory identifies several relevant execution paths involving:

• Fatal error handling.
• Error-reporting and diagnostic data.
• Session upload-progress processing.
• Incomplete cleanup of request-specific global state.
• Subsequent requests processed by the same worker.

Unlike a vulnerability limited to a single HTTP request, this flaw can involve interactions between consecutive requests.

For example, one request may leave behind invalid state, while another request triggers access to that state.

Researchers confirmed affected scenarios involving Apache mod_php and identified a PHP-FPM path that depends on application behavior and subsequent worker reuse.

The exact exploitability depends on the deployment architecture, PHP configuration, application behavior, and installed extensions.

Apache mod_php vs. PHP-FPM Exposure

The vulnerabilities may affect different PHP deployment models, but the available exploitation evidence is not identical.

The absence of a publicly demonstrated exploit for a particular configuration should not be interpreted as proof that it is secure.

Organizations should patch all affected PHP installations regardless of the web server or process manager being used.

Millions of PHP Hosts Potentially Exposed

According to reporting cited by BleepingComputer, VirusTotal estimated that more than 5.1 million PHP hosts are visible on the internet.

This number illustrates the potential scale of exposure but does not represent confirmed vulnerable or compromised systems.

The actual attack surface depends on PHP versions, server configurations, vendor backports, and whether affected services are accessible to untrusted clients.

Public reporting has also described early exploitation attempts and the availability of PHP2Shell testing tools, increasing the urgency of remediation.

Security Fixes Introduced by PHP

The PHP development team implemented changes to address both vulnerability classes.

Fix for CVE-2026-109618

PHP has modified its out-of-memory error-handling mechanism.

Instead of immediately abandoning operations in a manner that could leave internal request structures inconsistent, the updated implementation delays graceful memory errors until a safer execution point.

A separate hard limit addresses more severe memory pressure conditions.

Fix for CVE-2026-109619

The second fix strengthens cleanup and initialization of request-related global state.

PHP now resets a broader range of internal references to reduce the possibility of invalid memory references surviving between requests.

These changes address the underlying memory-management weaknesses rather than relying exclusively on request filtering.

Recommended Mitigation and Remediation

The PHP project states that upgrading to a fixed release is the complete mitigation.

Administrators should prioritize the following actions.

1. Update PHP Immediately

Upgrade to the appropriate patched version:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

Verify the PHP version installed on the server:

php -v

However, the command-line PHP version may differ from the version used by the web server.

Administrators should separately verify the active PHP-FPM service or Apache PHP module.

2. Restart PHP Workers

After applying updates, restart the affected services to ensure that running processes load the patched PHP binaries.

For example, depending on the operating system and PHP installation:

sudo systemctl restart php8.4-fpm

For Apache-based deployments:

sudo systemctl restart apache2

Service names vary by distribution and PHP version.

Confirm that every web-facing PHP worker is running the patched version.

3. Apply Temporary Risk-Reduction Measures

If immediate patching is not possible, the PHP advisory describes temporary measures for CVE-2026-109618.

These include:

• Administratively setting memory_limit=-1, as described in the advisory.
• Restricting maximum HTTP request sizes.
• Limiting multipart form submissions at the reverse proxy or web server.
• Reducing unnecessary public exposure.
• Avoiding RLIMIT_AS and RLIMIT_DATA, which may trigger allocation failures on vulnerable execution paths.

These measures are not complete protection and should only be used as temporary risk reduction until patching is completed.

4. Reduce Exposure to CVE-2026-109619

For the stale-state vulnerability, the PHP advisory does not provide a complete configuration-based workaround.

Depending on the deployment, administrators may reduce exposure by:

• Disabling fatal_error_backtraces on PHP 8.5 to eliminate one confirmed trigger.
• Disabling session upload-progress functionality where it is unnecessary.
• Reviewing application behavior involving fatal errors and request cleanup.
• Minimizing unnecessary PHP extensions and exposed functionality.

These actions address specific demonstrated conditions but do not eliminate all potential exploitation paths.

5. Monitor for Suspicious Activity

Security teams should review web server, PHP, and application logs for unusual behavior.

Potential indicators include:

• Repeated HTTP requests containing unusually large multipart form data.
• Unexpected PHP memory exhaustion errors.
• Repeated PHP worker crashes or restarts.
• Abnormal request-processing failures.
• Suspicious file uploads and unusual request patterns.
• Unexpected processes spawned by web server service accounts.

Log analysis may help identify suspicious activity, but the absence of errors or indicators does not guarantee that exploitation has not occurred.

Security Implications

PHP2Shell highlights the security risks associated with memory-management flaws in widely deployed web application runtimes.

Unlike vulnerabilities caused by insecure application code, these weaknesses exist within the underlying PHP engine.

As a result, even applications that implement authentication, input validation, and other security controls may remain exposed when running a vulnerable PHP version.

The confirmed unauthenticated exploitation path involving Apache mod_php is particularly significant because malicious requests can trigger the vulnerability before application code executes.

Organizations operating internet-facing PHP applications should treat these vulnerabilities as high-priority infrastructure security issues.

Conclusion

CVE-2026-109618 and CVE-2026-109619 represent critical vulnerabilities in PHP's core request-processing and memory-management mechanisms.

The demonstrated remote code execution risk, combined with PHP's widespread deployment across internet-facing applications, makes timely remediation essential.

Organizations should upgrade to the latest patched PHP releases, restart affected worker processes, verify active runtime versions, and monitor for suspicious activity.

Temporary configuration changes may reduce exposure, but they are not substitutes for installing the official security updates.

References

• PHP Security Advisory — CVE-2026-109618
• PHP Security Advisory — CVE-2026-109619
• PHP Foundation — Security Release and Security Improvements
• PHP2Shell Research
• PHP2Shell Vulnerability Coverage
• PHP Early Exploitation Attempts