Executive Summary
On October 21, 2026, the PHP project released emergency fixes for CVE-2026-109618, “RCE via OOM corruption” (GHSA-w8hw-w9fx-j79w) and CVE-2026-109619, “RCE via stale global state” (GHSA-6wmf-4rv5-p3rp). Both are rated 9.2 under CVSS v4.0, and neither requires authentication or user interaction. Researchers have named the pair PHP2Shell.
What makes PHP2Shell different from most web bugs is where it lives. Because the flaws are in the engine rather than in any site’s code, any website running a vulnerable PHP version can be attacked, even a basic one-page site. Keeping WordPress, Drupal, or Laravel up to date doesn’t help if the PHP underneath is out of date.
Key takeaways:
Scope is significant. PHP runs nearly 70% of websites where the server-side language is known, so the number of exposed sites is huge. Security vendors have counted more than 22 million internet-facing PHP instances that may be vulnerable.
Exploitation attempts started early. Amazon’s threat intelligence team spotted a PHP2Shell exploit attempt in its MadPot honeypots on October 17, four days before the flaws were made public.
Attempts are widespread. In the first 48 hours after disclosure, Versa’s lab environment recorded a lot of PHP2Shell-specific probes and attempts, but none of them were successful. Weaponized traffic also reused older PHP exploits such as CVE-2024-4577. No successful remote code execution was observed.
Source-level fixes are available. The PHP security team provided source-level fixes for 7.4, 8.0, and 8.1. These are intended for organizations that compile PHP from source or do not have access to a Long-Term Support (LTS) vendor.
Hidden PHP is the long tail. PHP is embedded in network appliances, control panels, and OT devices, and several security vendors have had to assess their own products.
AI changed the exploitability calculus. The underlying bug class was known for years; frontier AI models made a reliable exploit chain practical.
Disclosure Timeline
October 17, 2026: The earliest known exploitation attempt was observed in AWS MadPot honeypots.
October 20, 2026: A user published a post on the Hacker News forum revealing the vulnerabilities’ CVE identifiers, which were supposed to be kept secret until the patches were available.
October 20, 2026: The PHP security team gave advance notice of a security release set for October 21, 2026, at 14:00 UTC covering two critical vulnerabilities, each rated CVSS v4.0 9.2, without naming CVE identifiers.
October 21, 2026: The embargo was lifted, and the PHP team released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to address the two vulnerabilities.
October 21, 2026: The first external traffic related to these vulnerabilities was recorded in Versa’s lab environment.
October 22, 2026: Vendor advisories and national CERT guidance were published.
October 22, 2026: The first PHP2Shell exploitation attempt was observed in Versa’s lab environment.
October 23, 2026: PHP has since disclosed a separate session-handling flaw, CVE-2026-115560, which the October 21 releases do not fix.
The leak shortened the time defenders had to prepare. Chainguard published patched PHP builds before the embargo ended, which let attackers compare the old and new code and work out what had changed. As a result, exploit code, write-ups, and partial fixes were online before the official release.
Technical Analysis
CVE-2026-109618: Out-of-memory corruption
If PHP runs out of memory in the middle of certain operations, it leaves some request data half-built. When PHP then cleans up, it works on this broken data, which an attacker can turn into remote code execution. Datadog Security Labs, which reproduced the attack, describes three steps: trigger the interrupted operation, fill the half-built data with attacker-controlled content, and make PHP’s cleanup routine run a system command.
CVE-2026-109619: Stale global state (use-after-free)
PHP has a flaw where it fails to properly clean up after processing a request. It empties the memory used for the task but accidentally holds onto the links pointing to that old data. When the server handles the next request, it mistakenly tries to use those leftover, empty links before fully resetting itself. Security researchers have shown that attackers can exploit this memory confusion (known as a “use-after-free” error) to remotely run their own malicious code on the server.
The best-known attack path abuses PHP’s upload progress feature. This feature is turned on by default and works even if the website never uses sessions. As security researchers explain, the attacker pauses the upload for just over one second, which gets around a built-in limit on how often PHP updates upload progress. Blocking large requests doesn’t help, because this attack uses a very small request of about 450 bytes.
What the fix changes
The patch changes how PHP handles running out of memory. Instead of trying to clean up data that may be broken, PHP now stops the worker process immediately (exit code 137).
Exploitation Considerations
Reliability is improving. Reports state that the exploits rarely work on the first try. An attacker may need to send thousands of requests, which is easy to automate. VulnCheck found that public exploit code mostly fails on standard x86-64 servers with ASLR (a memory protection) turned on, but ARM64 servers are easier to attack by trial and error. The memory leak described earlier could help close this gap, because leaked memory can reveal the addresses an attacker needs.
For CVE-2026-109619, the attacker’s requests must land on the same PHP worker process. Servers with many workers make each attempt less likely to succeed, but they don’t fix the flaw.
Early traffic was mostly mass scanning, with attackers testing huge numbers of sites to find vulnerable ones. Real-world compromise data so far supports this picture. Mark Maunder, founder and CEO of Wordfence, reported that across the more than 5 million PHP sites Wordfence protects, the company has seen “exactly zero hacked sites from php2shell.” He noted that major exploitable vulnerabilities normally bring a wave of site cleanups, and this one has not. This matches what we saw in Versa’s lab environment, where no attempt led to code execution.
Neither CVE appears in the CISA KEV snapshot dated October 23, 2026. But that does not establish absence of exploitation.
Versa Threat Research Lab Observations
Versa Threat Research exposed an internet-facing lab environment running vulnerable PHP versions, capturing all inbound HTTP traffic from October 21. We recorded 15,443 external requests from 1,761 unique IPs.
| Category | Share |
| Background noise (fingerprinting and internet-wide scanners) | 67.0% |
| Reconnaissance (WordPress enumeration, open-proxy tests, Androxgh0st credential harvesting) | 15.7% |
| Weaponized legacy PHP exploit chain | 8.4% |
| React2Shell-style probe | 5.3% |
| PHP2Shell upload-progress probe | 3.6% |
Figure 1. PHP2Shell Style request seen on Versa’s lab environment.
Multiple requests matched an exposure check for the CVE-2026-109619 upload-progress path, but they were individual requests with no command payload, not the thousands of attempts reliable exploitation requires. They most likely came from a research scanner.
Botnets are still using yesterday’s PHP exploits. Much of the weaponized activity came from IPs using the libredtail-http user agent, consistent with the RedTail cryptomining botnet. Each ran the same four-stage chain within about 25 seconds: CVE-2024-4577 (PHP-CGI argument injection via a soft-hyphen bypass), the original CVE-2012-1823, a ThinkPHP invokefunction RCE, and a pearcmd.php LFI-to-RCE. The PHP-CGI payload drops an embedded SSH key and pulls a second stage from 217.60.102[.]5, falling back to wget or curl, and tags the run with cve_2024_4577. None of these chains target PHP2Shell. These botnets favor single-request, deterministic exploits, and PHP2Shell’s memory-corruption chains don’t yet fit that model.
No successful remote code execution was observed, matching Wordfence’s real-world data and the broader industry picture.
What this means
This is a single lab environment over a short window, so it shows attacker behavior rather than internet-wide volume. Still, it suggests that PHP2Shell is currently a threat from skilled operators rather than commodity botnets. That gap is the defender’s patching window, and it will close as public exploits mature. It also shows that old PHP bugs remain the bigger day-to-day threat.
Potential Impact on Organizations
The direct impact is code execution as the PHP worker account, which typically grants access to application credentials, database connections, and anything else the web tier can reach.
Three risks stand out. The first is the end-of-life backlog: industry estimates suggest about half of PHP systems won’t get a patch. The second is invisible PHP: many vendor applications bundle PHP without saying so, which makes the affected assets hard to find. Bundled standalone binaries such as php.exe and php-cgi.exe on Windows are easy to miss. The third is management interfaces on network and security devices, which attackers often target to get a foothold.
Recommended Mitigation Approach
- Patch and restart. PHP 8.2, 8.3, 8.4 and 8.5 are affected before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 respectively, when serving web requests. For end-of-life branches, the PHP security team published minimal source backports for PHP 7.4 through 8.1, and LTS distribution vendors ship backported fixes under their own version numbers.
- Inventory beyond web servers. Include appliances, control panels, Windows software that bundles PHP, and OT devices. Verify the effective web configuration, since Apache with mod_php needs a different check (inspect phpinfo() served through the web SAPI, not the CLI).
- Apply interim hardening where patching is delayed. PHP says updating is the only full fix. These settings only reduce risk:
- For CVE-2026-109618: set memory_limit=-1 so applications can’t change it, keep post_max_size low, and limit request sizes at the web server or proxy. Don’t use RLIMIT_AS or RLIMIT_DATA instead, because PHP warns these can trigger the same bug.
- For CVE-2026-109619: turn off upload progress (session.upload_progress.enabled=0) and, on PHP 8.5, set fatal_error_backtraces=0. Put these in php.ini or the PHP-FPM pool configuration, not in .user.ini or .htaccess, which may load too late. Then restart all PHP workers.
- Use network-level patching, If the steps above aren’t possible right away, use network-level protection, such as Versa IPS signatures, to block known exploit patterns while you update. Attackers are changing their payloads, so treat this as a stopgap, not a fix.
Versa’s Perspective
Versa Product Impact Assessment
Versa is not affected. Versa products are not affected by these vulnerabilities because they do not use the PHP runtime. No patches, upgrades, or configuration changes for Versa products are required on your part. Our Product Security team has reviewed the VersaONE Universal SASE Platform, including Secure SD-WAN, SSE, NGFW, Versa Director, Versa Analytics, and Concerto, and Versa-delivered cloud services, and confirmed that none of them include or depend on the PHP runtime.
Why Versa Products Are Not Impacted
Because VersaONE runs on VOS, an operating system Versa built and maintains itself, we know precisely which software components ship in our products. That is what allowed us to reach this conclusion quickly and with confidence.
Versa’s Detection and Coverage
Versa has released IPS signatures that detect and block known PHP2Shell exploitation patterns, including malicious multipart requests targeting the session upload-progress path and other exploit techniques seen in public proof-of-concept code and in the wild. These signatures are available in SPack version 2386 and are included in Versa Recommended Profile.
References:
- PHP Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- PHP Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Amazon Threat Intelligence, “PHP2Shell exploitation prior to public disclosure in MadPot”: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
- Datadog Security Labs, “PHP2Shell: detection, analysis, and remediation”: https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/
- Hacktron AI, “PHP2Shell: Critical PHP RCE”: https://www.hacktron.ai/blog/php2shell
- Cyber Security Agency of Singapore, Alert AL-2026-151: https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-151/
- heise online, “php2shell: Critical flaws allow code injection in PHP”: https://www.heise.de/en/news/php2shell-Critical-flaws-allow-code-injection-in-PHP-11494897.html
- The Hacker News, “PHP2Shell: Two Unpatched Critical PHP RCE Flaws”: https://thehackernews.com/2026/10/php2shell-two-unpatched-critical-php.html
- Infosecurity Magazine, “Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patch”: https://www.infosecurity-magazine.com/news/critical-php-vulnerabilities-leaked/
- Help Net Security, “PHP2Shell: Critical PHP vulnerabilities patched, update now!”: https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
- Mark Maunder (Wordfence), post on X: https://x.com/mmaunder/status/2113354287233614321
- CISA, “Critical Vulnerabilities in PHP Require Immediate Patching”: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
