Attackers are targeting two critical vulnerabilities in PHP. The vulnerabilities, collectively known as PHP2Shell are tracked as CVE-2026-109618 and CVE-2026-109619, and could allow unauthenticated attackers to execute arbitrary code on vulnerable web servers or extract sensitive information from process memory.
Both vulnerabilities carry a CVSS v4.0 score of 9.2 (Critical) and affect PHP’s core runtime rather than individual applications. This makes the potential impact particularly widespread, extending to websites and services built on WordPress, Drupal, Joomla, and other PHP-based technologies.
How the PHP2Shell Vulnerabilities Work
PHP2Shell refers to two related memory-safety vulnerabilities in the PHP engine. Both involve how PHP handles internal memory when a request terminates unexpectedly, but they affect different stages of request processing.
CVE-2026-109618 – Remote Code Execution via Out-of-Memory Corruption
This vulnerability occurs when PHP encounters an out-of-memory condition while internal request data is only partially initialized. Under certain circumstances, PHP interrupts processing without properly restoring its internal state. During request cleanup, the engine may subsequently access invalid memory as though it contained legitimate data.
Attackers can trigger the vulnerable condition using specially crafted HTTP requests, including multipart form submissions designed to exhaust memory during input processing. These requests can exploit inconsistencies between PHP’s request-size limits and the actual memory required to process incoming data.
The vulnerability is particularly dangerous in Apache deployments using mod_php. Researchers demonstrated that an unauthenticated request could trigger memory corruption and achieve remote code execution before any application-specific PHP code runs.
CVE-2026-109619 – Remote Code Execution via Stale Global State
The second vulnerability stems from PHP retaining references to memory belonging to a previous request.
When a fatal error interrupts processing, certain internal structures may not be reset correctly. Although the request’s memory is subsequently released, references to it can remain accessible to the same PHP worker.
A later request handled by that worker can access the stale references, creating a use-after-free condition. By manipulating the underlying memory layout, attackers can potentially turn this condition into remote code execution or information disclosure.
One confirmed exploitation path involves PHP’s session upload-progress functionality, which is enabled by default. Researchers also identified exploitable conditions involving fatal-error backtraces and other persistent internal state.
Importantly, these vulnerabilities do not depend on a weakness in WordPress, Drupal, or another application. In testing conducted by Wiz Research, researchers demonstrated unauthenticated remote code execution against all three major content management systems, alongside application-independent memory disclosure.
The implications extend beyond attackers gaining a shell. Successful memory disclosure could expose credentials, authentication tokens, API keys, and other sensitive information without requiring conventional command execution.
Attackers Were Targeting PHP2Shell Before Disclosure
The timeline surrounding PHP2Shell has become one of the most concerning aspects of the incident.
The vulnerabilities were originally scheduled for coordinated public disclosure on October 22. However, information about the flaws leaked on October 20, prompting the PHP security team to bring forward the release of its security updates to October 21.
Newly published findings suggest that attackers were already experimenting with the vulnerabilities before those details became public.
Amazon Threat Intelligence identified an attempted PHP2Shell exploit against its MadPot honeypot infrastructure on October 17, 2026. The activity originated from infrastructure associated with a commercial anonymization service.
Additional attempts were detected between 02:00 and 08:00 UTC on October 21. Amazon observed differences in the payloads and anonymization infrastructure used, suggesting that multiple actors were attempting exploitation independently.
Following the public release of the patches, additional proof-of-concept exploits appeared, and Amazon observed them being used against its sensors almost immediately. The company now describes PHP2Shell exploitation attempts as widespread, although it has not established whether the observed attempts would have succeeded against production systems.
Cloudflare also reported seeing attackers modify their payloads in attempts to evade its protections. The company had deployed initial WAF rules to customers across all plans before the public disclosure.
Affected PHP Versions and Potential Impact
The vulnerabilities affect PHP installations serving web requests, including deployments using Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed.
According to the PHP security advisory, the following versions contain the fixes:
| PHP branch | Fixed version |
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
PHP 8.1 and older versions are also affected but no longer receive regular security releases from the PHP project. Some Linux distributions and long-term support vendors provide backported fixes, while the PHP security team has made minimal source-level backports available for PHP 7.4, 8.0, and 8.1.
According to W3Techs, PHP is used by approximately 69.3% of websites whose server-side programming language can be identified. Its widespread presence in web applications, content management systems, and business platforms creates a substantial attack surface.
Indicators of Compromise and Detection Opportunities
Amazon published six IP addresses associated with the exploitation attempts observed in its honeypot environment.
| IP address | Observed date |
| 103.216.220.92 | October 17, 2026 |
| 31.223.184.166 | October 21, 2026 |
| 37.19.200.5 | October 21, 2026 |
| 134.209.159.64 | October 21, 2026 |
| 103.114.163.188 | October 21, 2026 |
| 95.217.98.37 | October 21, 2026 |
These addresses include shared anonymization infrastructure and should be treated as investigative indicators rather than definitive proof of malicious activity. A connection involving one of these addresses does not, by itself, establish compromise.
Security teams should also monitor for behavioral indicators consistent with PHP2Shell exploitation.
- Unusual HTTP POST requests: Multipart form submissions containing unusually large field names, excessive headers, or the PHP_SESSION_UPLOAD_PROGRESS parameter, particularly when followed by errors or abnormal server behavior.
- PHP memory errors and process crashes: Repeated out-of-memory exceptions, fatal errors, or unexpected termination of PHP-FPM and Apache workers, especially when correlated with requests from the same source.
- Suspicious process execution: PHP or web server processes spawning shells, command interpreters, download utilities, or other unexpected child processes.
- Unexpected file modifications: Newly created PHP files in web-accessible directories, unfamiliar plugins, modified application files, or unauthorized persistence mechanisms.
- Suspicious outbound connections: Unexplained network connections initiated by web server processes, particularly those involving newly contacted external infrastructure.
Defenders should be aware that memory disclosure or code execution contained entirely within the PHP process may not generate obvious child-process activity. The absence of endpoint alerts therefore does not rule out exploitation.
For network-level visibility, Corelight has published open-source Zeek and Suricata detections designed to identify suspicious request patterns and potentially vulnerable PHP versions.
These detections can supplement existing SIEM and endpoint monitoring, although inspection of HTTPS request content requires appropriate visibility into decrypted traffic.
Mitigation and Recommended Actions
The PHP security team has emphasized that upgrading to a patched release is the only complete remediation. Configuration changes and web application firewall protections may reduce exposure to known attack methods but cannot eliminate every exploitation path.
Organizations should prioritize the following actions:
- Patch affected PHP installations immediately. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or apply a verified vendor-supported backport. Confirm that all PHP workers and relevant web services have restarted and are running the patched code.
- Identify legacy and unmanaged PHP deployments. Review internet-facing websites, internal applications, containers, third-party products, and hosted services that bundle PHP. Systems running end-of-life versions should be migrated to supported releases wherever possible.
- Apply temporary exposure-reduction measures where patching is delayed. Keep WAF protections enabled, restrict unnecessary multipart uploads, and enforce appropriate request-size and input-processing limits. The PHP security team also documents configuration measures involving memory_limit, session.upload_progress.enabled, and fatal_error_backtraces for specific attack paths. None should be treated as a complete workaround. High-risk services that cannot be protected or patched should be considered for temporary isolation.
- Investigate potential exploitation dating back to October 17. Review web server access logs, PHP error logs, network telemetry, endpoint activity, and recent file changes. Systems showing credible evidence of exploitation should undergo incident-response investigation, including assessment of possible credential exposure and persistence.
Organizations using managed hosting should confirm that their provider has updated the underlying PHP runtime. Updating an application’s plugins, themes, or dependencies alone does not remediate vulnerabilities located in the PHP engine.
Stay Safe. Stay Secure.
OP Innovate Research Team
