Amazon logged an exploit attempt four days before PHP shipped fixes. About 48% of PHP sites run branches without a fixed release, leaving many operators facing an upgrade or a source backport.
Amazon's honeypots logged an attempt to exploit the PHP flaws on 17 October. PHP shipped fixes four days later, on 21 October.
The failure was in the disclosure embargo; the patch itself was not the problem. Coordinated disclosure assumes only the discoverers know about a bug, and that stopped being true before the release date. The cost falls on operators who cannot patch on the day, such as shared hosting platforms and sites on branches PHP no longer maintains.
About half of PHP sites have no released fix to install. On W3Techs' 22 October count, PHP 8.2 to 8.5 run on 51.6% of PHP sites, and those branches have a fixed release. Branches 8.0, 8.1, 7.x, 5.x and 4.x hold the other 48.4%.
PHP offers limited help for older branches and says 8.1 and older no longer receive updates. It built source backports, which are code patches for people who compile PHP themselves, for 7.4, 8.0 and 8.1 only. Sites on 5.x, 4.x and most of 7.x have nothing.
The 48% is a ceiling for that group. Linux distributions often backport fixes without changing the version string, so some of these sites are protected. The other 52% have a release to install, but W3Techs counts branches and cannot show who has installed it.
The fixes and the first attempts
Two critical flaws sit behind the patch. The PHP project's advisory says releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix them, and both can allow unauthenticated remote code execution.
They are CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on the CVSS v4.0 scale. PHP calls updating the only complete mitigation. It says the risk is highest for the mod_php Apache module, where one request can trigger the attack before any application code runs.
Amazon's threat intelligence team dates one attempt to 17 October, from a single address on a commercial anonymisation network. It places the earliest proof of concept at about 02:00 UTC on 21 October, twelve hours before the release.
The 17 October actor remains unexplained. Amazon says it is unclear how that actor learned the exploit, and unclear whether any of the 21 October attempts would have succeeded. Attempts between 02:00 and 08:00 UTC suggested several actors.
PHP's own team saw no working exploit. The PHP Foundation says it inspected proofs of concept after the leak and found no functional exploit at release time. The two accounts are compatible.
Amazon saw one early probe, and the PHP team found no working tool in circulation at release. The four days measure how long defenders were exposed to that probe.
The 12 hours between the earliest proof of concept and the release show how fast attackers moved once working code existed. They are shorter than most patch policies allow. Amazon writes that a seven day or 30 day patch policy assumes a delay between patch and exploit that no longer exists.
How disclosure broke down
Many parties knew of the bug long before the release. Calif reported an unconditional remote code execution on 11 August, and OpenAI reported the same root cause that day. Wiz added attack vectors on 24 August and OpenAI more on 18 September.
PHP had known longer still. A 2024 external audit led a contractor to the first signs of the out of memory problem. The security team then built several competing fixes, each with costs, and the Foundation calls the delay "a structural failure".
Details leaked in the final two days before release. Around 15:00 UTC on 20 October the two CVE ids began circulating on forums with a wrong score of 10.0.
PHP pulled its release forward from 22 October to 21 October. Around 20:00 UTC, Calif mistakenly published a video of its working proof of concept.
Cloudflare gives a second source beside Amazon. Its chief executive said the company saw thousands of attempts in the 10 hours before the announcement. He put the count at tens of thousands in the 45 minutes after it and millions by 22 October.
PHP blames Chainguard for the early exposure. At 07:41 UTC on 21 October, more than six hours before the release, Chainguard published built images that contained the fix. The Foundation says any attacker could then study the fix in binary form.
Chainguard's chief executive disputes the charge. He told The Register that a researcher tipped the company off on the Friday, and that its own tooling then found the bugs. He said people "were getting hit in advance" of the official disclosure, so he made the call to ship early.
Chainguard's chief executive also denies any leak. He said Chainguard "didn't leak". He wrote on LinkedIn that a "basic prompt of 'find bad vulnerabilities in PHP'" was all it took.
Amazon's 17 October attempt predates both the forum leak and Chainguard's publication. Whoever is right about the embargo, the first attempt came before either.
The choices facing hosts
Shared platforms feel this first. On 20 October Wikimedia took Cloud Services offline as a precaution. Individual project maintainers manage the software on their own instances.
Wikimedia wrote that "we cannot centrally guarantee that every instance has been updated". It said it was prioritising the safety of its systems over availability. It will bring PHP Toolforge tools and Cloud VPS projects back last, after review.
Governments also took systems offline. The Register reported that Finnish government services and websites of the Dutch parliament were taken offline as a precaution.
The formal record also undercounts the exposed base. The CVE entries list only 8.2.x to 8.5.x as affected. Wiz says every PHP release back to 5.4 carries at least one of the flaws.
Hosts that let tenants pick their PHP version now face a choice. They can force upgrades and break tenant applications, or switch tenants off, as Wikimedia did. A managed runtime, where the provider sets the PHP version, trades tenant flexibility for control of its own maintenance window.
Exposure beyond websites
Devices that embed PHP are harder to fix. The NCSC-NL and CERT-EU repository notes that the impact is not limited to websites. It lists QNAP products whose fixed versions are "to be announced".
A joint statement from European agencies warns that some organisations may be affected even if they do not appear to use PHP directly. It comes from the European Commission, ENISA, CERT-EU, Europol's cybercrime centre and the national CSIRTs network. It tells organisations to take immediate action, prioritise internet facing systems and, where remediation is not feasible, consider isolating exposed applications from public networks.
On 31 December PHP 8.2 stops receiving security fixes. It runs on about 18% of PHP sites on W3Techs' count. Every site still on it then will sit in the group with no project fix path.