On October 21, the PHP project shipped emergency fixes for two flaws that let an unauthenticated attacker run code on servers running PHP, which powers roughly 70% of websites. Nobody tampered with a build, hijacked a maintainer account or poisoned a package, so the software supply chain security stack built after SolarWinds and xz had nothing to catch: a correctly signed, fully attested PHP binary was the vulnerable artifact. The signatures and software bills of materials (SBOMs) did what they were designed to do, which is to show that an artifact has not been tampered with. What failed were the links that most supply chain programs never measure, because those programs model the supply chain as a sequence of artifacts, while the chain that PHP2Shell tested also consists of the people who maintain the code, the processes that govern disclosure and the systems where the code actually runs: an underfunded upstream, an embargo run on trust, downstream inventory that could not answer a basic question, and credentials that no patch can take back.
The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, covering CVE-2026-109618 and CVE-2026-109619. CISA, the NSA and the UK NCSC told organizations that could not patch quickly to consider taking affected systems offline, and several Canadian federal and provincial sites did exactly that.
Patch, Restart, Rotate: What to Do This Week
If you run PHP anywhere, there are three measures you should complete this week, before you turn to the structural weaknesses discussed below.
- Patch and restart. Move to PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a patched vendor build. Restart every PHP service and rebuild images built on PHP bases.
- Inventory runtimes, not apps. Include PHP bundled in appliances, hosting panels and vendor products. Ask critical suppliers directly whether they run PHP, whether they have patched and restarted, and when they will finish.
- Assume secrets have leaked since at least October 17. Amazon recorded an exploitation attempt on that date, so treat secrets held by exposed PHP workloads as potentially disclosed and rotate first those that reach other systems.
One of Your Most Critical Suppliers Has No Contract
The supplier that mattered most on October 21 answers no questionnaires, offers no service-level agreement and appears in few supplier registers. Yet PHP sits beneath government services, retailers and banks, and the project's security work still rests on a small group of Foundation-funded developers plus volunteers.
The PHP Foundation's own account of the incident is candid about its shortcomings. A Foundation-contracted core developer found the first signs of the out-of-memory flaw behind CVE-2026-109618 in 2024, while fixing an issue from an external audit funded by Germany's Sovereign Tech Agency. The security team produced several candidate fixes, each with a cost, and could not reach consensus. The Foundation calls the delay “a structural failure.”
The fix became the top priority only after Calif and OpenAI independently reported a working attack path on August 11, 2026. Since July 1, the team has published 15 CVEs and worked through more than 100 invalid, duplicate or unreproducible reports, a volume the Foundation links to AI-assisted research.
An SBOM can tell you that you depend on PHP, but it cannot tell you that the fix for a known memory-safety issue had stalled since 2024 because a small, stretched security team could not settle on one.
The Embargo Leaked from Every Side
Coordinated disclosure depends on intermediaries. Linux distributions, LTS vendors and hardened-image providers get patches early so their customers can update the moment details go public. PHP2Shell showed how loosely that trust tier is governed.
According to the PHP Foundation's timeline, the CVE identifiers were circulating on forums by around 15:00 UTC on October 20, with the wrong severity score and release time. That evening, Calif mistakenly published a video of its proof of concept; it was deleted, but copies spread, and the Foundation says this accelerated public exploit development. Mitigation advice shared with a few critical infrastructure providers may also have leaked.
Then, at 07:41 UTC on October 21, more than six hours before the coordinated release that the leaks had already forced forward by a day, Chainguard published built images containing the fix. The Foundation says this broke the embargo and let any attacker study the patch in binary form while other users waited. Chainguard's CEO, Dan Lorenc, has said the company shipped early because of reports of exploitation in the wild, which a PHP Foundation board member has disputed, described the volume of such disclosures as “the new normal for the industry,” and apologized to the Foundation for the extra stress.
The trouble may have started earlier still. Amazon reports that its MadPot honeypot network recorded a PHP2Shell exploitation attempt dated October 17, four days before disclosure, and says it is unclear how the actor got the information.
None of this requires bad faith from any single party, because pre-disclosure access runs on trust and convention, and when you choose a distribution or image vendor, you also choose how it behaves under embargo, a question that few procurement processes ask.
Nobody Could Answer, “Where Does PHP Run?”
That was the first question most CISOs faced on October 21. CISA warned that PHP is often a component of other software and that its prevalence may not be directly observable. CERT-EU pointed organizations to a GitHub repository maintained by the Dutch NCSC, which NCSC-NL itself describes as incomplete and still growing.
A crowdsourced list is a sensible emergency measure, but its existence shows that, several years into SBOM mandates, most organizations still cannot answer a runtime inventory question by running a query.
The runtime itself complicates remediation, because updating WordPress or Drupal does not touch the flaw: researchers stress that PHP workers must be restarted after the upgrade, and container images built on a PHP base must be rebuilt and redeployed, not merely rescanned.
End-of-life versions widen the gap further, because they get no official release: PHP 7.4, 8.0 and 8.1 receive only minimal source backports, while researchers report affected releases going back to PHP 5.4. Those runtimes, buried in appliances and control panels, are exactly what SBOM programs tend to miss.
Patching Cannot Recall Leaked Secrets
CVE-2026-109619 can disclose PHP worker memory without code execution. PHP's advisory confirms memory disclosure as an impact, and the researchers say that memory can include passwords, authentication tokens, API keys and certificates belonging to other requests. Patching stops further leakage, but it does nothing about secrets that may already have been exfiltrated.
This turns PHP2Shell into a non-human identity problem as well as a vulnerability problem. The credentials at risk are the ones applications hold to reach databases, payment providers, cloud APIs and partners. If you cannot say which secrets a PHP workload holds, or rotate them quickly, you are stuck choosing between an expensive blanket rotation and an assumption you cannot evidence.
Fix the Chain This Year: Four Measures for Your Roadmap
- Score upstream health. Add maintainer depth, security process and funding to third-party risk. For components as central as PHP, sponsoring the maintainers is a risk control and deserves to be budgeted alongside the other controls you fund.
- Put embargo conduct in contracts. Agree with distribution, LTS and hardened-image vendors what they receive before release, and when they may ship it.
- Test your SBOM against this scenario. Extend SBOM programs to runtime and base-image inventory, then time it: how long does it take to list every system running a given interpreter version?
- Measure rotation time. Track how long it takes to rotate the credentials each workload holds, and report it as a resilience metric alongside patch latency.
Built for May, Tested in October
The PHP ecosystem did see conventional attacks this year. In May, attackers rewrote release tags across four Laravel-Lang Composer packages, producing more than 700 malicious versions, and a separate campaign hit eight Packagist packages, which is exactly the kind of tampering that supply chain security tooling is designed to catch. KuppingerCole's 2026 Leadership Compass on Software Supply Chain Security named attestation as the market's weakest capability, but stronger attestation would not have changed October's outcome.
At the same time, discovery is getting cheaper. AI-assisted research turned a weakness first noticed in 2024 into working attack paths from several directions in quick succession: Calif and OpenAI on the same day in August and Wiz less than two weeks later, and earlier in the year the Foundation had already scanned PHP with Anthropic's Claude Mythos through the Alpha-Omega project. Choosing the right fix for a long-standing design decision, reviewing it and shipping it across every distribution under embargo is not getting cheaper at the same rate.
As discovery gets cheaper, your exposure depends less on the integrity of the artifacts you consume and more on the capacity of upstream maintainers to fix what is found, the discipline of the intermediaries who distribute those fixes, and your own ability to find affected systems and rotate what they hold, so a supply chain program that measures only artifact integrity will keep meeting incidents shaped like this one. Patch, restart and rotate this week; put upstream health, embargo terms, runtime inventory and rotation speed on your 2027 roadmap. To see how vendors compare on the capabilities this market does address, read KuppingerCole's Leadership Compass on Software Supply Chain Security.
