On 21 October 2026, the PHP Foundation shipped emergency patches for two critical memory-corruption vulnerabilities in PHP core, collectively named PHP2Shell:
CVE-2026-109618 (CVSS 9.2)
CVE-2026-109619 (CVSS 9.2)
Both allow pre-authentication remote code execution. They were found by researchers at Calif, OpenAI and Wiz, and they affect every release in the PHP 7.x and 8.x series.
The reason this matters more than a typical critical CVE is where the flaw lives. This is not a bug in WordPress, or Magento, or a plugin. It is a bug in the engine those things run on. CrowdStrike's analysis puts it bluntly: there is no authentication to bypass, no session to steal, and the exposure does not depend on which CMS, framework or plugins you happen to use.
Cloudflare notes that PHP is used by almost 70% of websites.
This isn't a story about any one security vendor's response. It is an internet-scale vulnerability in the most widely deployed web runtime there is, with a disclosure process that fell apart and exploitation that began before the public knew.
What happened
The vulnerability
The PHP Foundation explained that both issues sit in memory management and error handling, parts of PHP that nearly every request touches. That central position is what made them severe, and also what made them hard to fix without breaking compatibility, hurting performance, or forcing changes on the large ecosystem of third-party extensions.
CrowdStrike confirmed through testing that a single unauthenticated POST request is enough to make an Apache mod_php worker start a shell and execute a command of the attacker's choosing, with no vulnerable application code required. CrowdStrike reproduced the issue with memory_limit lowered to 16M and post_max_size raised to 64M purely to keep the test payload small, noting the same bug is reachable with larger payloads against normal limits.
The practical consequence: every reachable PHP endpoint on an affected server is a risk, including static forms, login routes and health checks. There is no vulnerable endpoint to find, because any endpoint will do.
The forensics problem
This is the detail that should worry incident responders most.
According to CrowdStrike, worker processes remain stable, responses return HTTP 200, and application logs record no anomalies, because no application code ever ran. The only server-side trace is a single memory-limit fatal error in the web server's error log, which is routinely dismissed as noise.
In other words, the attack leaves virtually nothing for defenders to find. If you are trying to determine retrospectively whether you were hit, your web telemetry will probably not tell you.
The disclosure went wrong
Coordinated disclosure was scheduled for 22 October at 14:00 UTC. It did not hold.
CVE details and a proof-of-concept exploit leaked early, prompting the PHP Foundation to bring the release forward by a day.
Separately, Chainguard unilaterally broke the embargo and published built images containing the fix. Chainguard had received the patch in advance so its users could update at disclosure. The PHP Foundation's objection is precise and worth understanding: any attacker could now study the fix in binary form while every other PHP user was still waiting for the release.
ELLIO observed its first PHP2Shell request at 08:36 UTC on 21 October, less than an hour after the Chainguard images went up.
Exploitation began before disclosure
Amazon's Threat Intelligence team detected an exploit attempt against its MadPot honeypot on 17 October, four days before the patches existed publicly, from an IP address geolocated to Australia and associated with a commercial anonymisation network.
Amazon's CISO, CJ Moses, noted that targeting a honeypot from an anonymised address while the vulnerability was under embargo suggests a threat actor, though it remains unclear how the actor obtained exploit information before disclosure.
After the patches landed, exploitation became broad quickly. Amazon flagged the earliest post-release attempt at around 02:00 UTC on 21 October, followed by six hours of attempts from anonymised infrastructure, with payload variety indicating multiple separate threat actors.
Scale of exposure
VulnCheck's internet-wide analysis found PHP on 2,608,039 internet-facing hosts:
PHP version range | Hosts | Status |
|---|---|---|
3.x through 7.3 | over 700,000 | End of life, no fix coming |
7.4, 8.0, 8.1 | about 400,000 | End of life |
8.2 through 8.5 | 403,000 | Supported, patchable |
More than a million internet-facing hosts are running PHP versions that will never receive a patch for this.
Why it matters
The attack surface is the web itself. A vulnerability in a CMS affects users of that CMS. A vulnerability in PHP core affects everyone running PHP, regardless of what they built on top of it. Cloudflare has already observed attackers mutating payloads to evade WAF rules, and WebOps platform Pantheon reported blocking over 60,000 suspicious requests probing the flaws.
Invisible exploitation breaks the post-incident playbook. When the only artefact is an error-log line that looks like routine noise, "check whether we were hit" stops being a straightforward question. Organisations will need process-level telemetry rather than web logs, which is exactly what the FBI advised: watch for PHP processes unexpectedly launching command shells or downloading files.
Coordinated disclosure is fragile at this scale. With a dozen vendors needing advance access to prepare protections, the number of parties who can break an embargo grows accordingly. One company publishing early compressed the defender's head start to under an hour.
AI is now on both sides of the vulnerability lifecycle. These flaws were found with AI assistance by researchers at OpenAI, Wiz and Calif, which is the defensive half. Amazon's Moses described the offensive half: the dependency on a small number of capable actors to build exploits is weakening, because AI-assisted analysis makes turning a patch diff into a working exploit cheaper, so more actors can act within hours or even minutes.
That is the structural change worth internalising. The window between a patch shipping and a weaponised exploit existing is no longer measured in weeks.
End-of-life PHP is now an active liability. Over a million exposed hosts cannot be patched. For those systems the options are upgrade, virtual patching at the edge, or removal from the internet.
Who is affected
Any organisation running PHP 7.x or 8.x on an internet-facing server, which is most of the web.
WordPress, Magento, Drupal, Laravel and Joomla estates, not because of a flaw in those platforms but because they run on the affected runtime.
Hosting providers and agencies managing large numbers of client sites on shared infrastructure.
Organisations running unsupported PHP, over a million internet-facing hosts by VulnCheck's count, who have no patch available.
Anyone with PHP bundled inside an appliance, OS distribution or vendor product, which is the long tail Sonatype's Ilkka Turunen warned about and the hardest category to inventory.
What organisations should do
Immediately
Patch to a fixed PHP release now. CISA and the UK NCSC have both urged organisations to apply the fixes as soon as possible or consider taking affected systems offline.
Find your PHP. Inventory every internet-facing service running PHP, including bundled instances inside appliances and vendor products. You cannot patch what you have not found.
If you cannot patch, mitigate at the edge. AWS, Cloudflare, Akamai, Fastly and Imperva have all published WAF mitigations. Treat these as temporary, given Cloudflare has already seen payload mutation designed to defeat them.
Check whether you are vulnerable using the checker OpenAI published for testing a website or local PHP binary.
Prioritise unsupported versions for upgrade or removal. PHP 7.3 and earlier will not be fixed.
Detection, given the lack of web telemetry
Monitor for PHP processes spawning shells. The FBI's guidance is specific: watch for PHP unexpectedly launching command shells or downloading files, and make sure process monitoring is actually in place.
Do not rely on web server access logs. Successful exploitation returns HTTP 200 with no application log anomalies.
Search error logs for memory-limit fatals, which may be the only server-side artefact. Treat clusters of them as worth investigating rather than as noise.
Ingest vendor detection content. CrowdStrike has added PHP2Shell detection to Falcon Next-Gen SIEM, and comparable content is available from most major vendors.
Hunt for the known scanning infrastructure, including the user agent
php2shell-scan/109618identified by VulnCheck, and review traffic back to 17 October.
Assume compromise where exposure was long
If an unpatched, internet-facing PHP server was live through 21 October, treat compromise as plausible and investigate at host level rather than concluding from clean web logs that nothing happened.
Check for persistence, including web shells, modified cron jobs, new accounts and outbound connections from web server processes.
Rotate credentials and secrets reachable from the web server. The NSA noted these flaws can give a direct path to the server's file system or database.
Final thoughts
A single unauthenticated POST request, sent to any PHP endpoint at all, that runs a command and leaves the access log reading HTTP 200. That is the whole attack. No vulnerable plugin to find, no login to defeat, no useful trace left behind.
The lesson: when a vulnerability lives in the runtime rather than the application, every assumption built on application-layer defence stops applying. Your WAF rules target known payload shapes and attackers are already mutating around them. Your access logs show success. Your application logs show nothing, because your application never executed. Defence here has to move down a layer, to process behaviour on the host.
The second lesson is about time. Exploitation was attempted four days before disclosure, by someone who should not have had the information. After release, multiple actors were active within hours, and the first request arrived within an hour after one vendor broke the embargo. Amazon's assessment is that AI-assisted analysis is compressing the patch-to-exploit interval for structural reasons that will not reverse.
If your patching process assumes you have a few days of grace after a critical advisory, that assumption has now failed twice in a week, in public.
Two things to do today: find every PHP instance you are exposing to the internet, including the ones inside other people's products, and check whether your monitoring would notice a PHP process starting a shell.
