A website can have up-to-date pages and plugins while the software underneath remains vulnerable. That is the immediate problem behind PHP’s October 21 emergency release: two flaws in the server software could let an outsider run code without logging in. PHP published fixes across all four supported branches, not just its newest version.
AI-assisted research helped establish the danger. But the release also reveals work that a successful bug report does not finish: choosing a repair that will not break existing software, getting it into packages, and making sure the website actually runs the corrected version.
The problem sits underneath the website
PHP runs on a server, turning application instructions into the pages and responses people receive. The flaws concern what happens when that machinery runs into an error, rather than a mistake in one website’s own code.
In one case, PHP can run out of memory while internal data is only partly prepared, then mistakenly use that unfinished data during cleanup. In the other, a later request can encounter a leftover reference to memory that has already been released. These are failures in the runtime, the software executing the application.
PHP’s advisory treats installations serving web requests as at risk. It identifies Apache’s mod_php configuration as the highest demonstrated risk, including an attack before application code starts. The conditions matter: this is not evidence that every PHP website has been compromised.
Finding the danger was not the same as choosing the repair
The PHP Foundation’s account puts the first signs of the memory-exhaustion problem in 2024. Its full remote-code-execution impact became clear through reports in August 2026, including work by Calif and OpenAI. Wiz also independently investigated the flaws, using AI tools alongside its researchers.
The Foundation describes competing repairs with uncomfortable costs: breaking compatibility, creating new denial-of-service risks, or requiring changes across third-party extensions. A small group of deeply experienced engineers struggled to settle on a choice. The organization attributes the delay to its decision process and limited resources, and says it is changing both. It is also seeking funding; this is its institutional account, not an independently measured staffing experiment.
AI can help reveal why a bug matters and sort related reports. It does not remove the need to decide which existing behavior a repair can safely change. The Foundation says people still make the decisions and work on every patch.
Attackers do not have to wait for the announcement
AWS reported finding an October 17 exploitation attempt in MadPot, its network of decoy systems. That was four days before public release. It also found further attempts before the October 21 disclosure and says exploitation broadened afterward.
The distinction is important: AWS does not establish that those early attempts would have succeeded against real systems. Nor does its evidence establish that the attackers used AI. What it does show is that the public announcement cannot be treated as the beginning of all hostile activity.
The release date itself moved forward by a day after vulnerability identifiers circulated, according to the Foundation. Distributors were still preparing packages. Releasing the code and giving users a practical update route were separate coordination problems.
A filter buys protection; it does not replace the runtime
The fixed upstream releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Linux distributions and long-term-support vendors may supply their own packages or backported fixes, including for older branches. The relevant question is whether the installed build contains the fix, not simply whether its version number looks newer.
Cloudflare’s own explanation makes the operational distinction unusually clear. A web application firewall can filter suspicious traffic, but updating a website’s application or plugins alone does not repair PHP underneath. Cloudflare still tells customers to apply the PHP update despite its additional firewall protections.
For a managed website, that may make the hosting provider the party that must act. The UK National Cyber Security Centre’s guidance also calls attention to products and services that bundle PHP, not only obvious standalone installations. The project and provider advisories are the place for deployment-specific instructions; no single temporary configuration change closes every path.
The same broader distinction appears in OpenAI’s account of coding agents weakening monitoring: producing a technical result and ensuring that a working system remains safe are different responsibilities. Here the final test is concrete. A flaw has not been fixed for a website merely because someone found it, wrote a patch, or announced a release. The software handling that website’s requests has to contain the repair.
Related: the original PHP release and other current developments.
Sources and further reading
- PHP: October 21 security advisory and fixed releases
- PHP Foundation: discovery, repair choices and coordinated release
- Wiz: PHP2Shell research and AI-assisted investigation
- AWS: pre-disclosure attempts observed in MadPot
- Cloudflare: firewall protection and runtime patching
- UK NCSC: affected systems and vendor updates

