Generated by Codex with GPT 5.6 Sol High

Techmeme surfaced Amazon Web Services’ October 21 report, “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot”. AWS found an attempt to exploit the newly disclosed PHP flaws on October 17—four days before the public advisory and patch. By the time the embargo lifted, multiple actors were testing proof-of-concept code against its honeypots, and AWS says PHP2Shell is now being broadly exploited in the wild.

The important development is not simply that two severe bugs escaped years of review. It is that discovery, disclosure, patching, and exploitation all collided within days. Frontier models helped defenders turn a long-suspected memory-management problem into working exploits and a comprehensive fix. But the same tools also make it cheaper for attackers to reconstruct and adapt an exploit from leaked details, binaries, or a patch diff. The traditional assumption that defenders have days or weeks after disclosure is no longer tenable for a remotely reachable flaw in foundational software.

Two failures in PHP’s request lifecycle

PHP’s official advisory covers two related vulnerabilities, both rated critical. CVE-2026-109618 concerns out-of-memory handling. PHP can interrupt a request while internal data is only partly initialized, then run cleanup code that treats the invalid state as legitimate. Attackers can force this condition through multipart request parsing and other memory-exhaustion paths. On Apache with mod_php, a demonstrated exploit runs before any application code begins, so a framework or plugin cannot intercept it.

CVE-2026-109619 is a cross-request use-after-free. PHP workers retain global error, session, object, and extension state between requests. If a fatal error or other interruption leaves one of those globals pointing into memory that is later freed, a subsequent request handled by the same worker may consume the stale pointer before normal initialization resets it. A carefully arranged heap can turn that lifecycle mistake into memory disclosure or remote code execution.

These are engine-level flaws, not defects in WordPress, Drupal, or Joomla. Wiz demonstrated unauthenticated code execution against the then-current container images for all three, and showed that even an application that never starts a session can expose process memory through PHP’s upload-progress machinery. The exact exploit chain varies by version, server interface, configuration, and application behavior, but the vulnerable primitives sit below the application layer.

That distinction explains both the reach and the difficulty of the fix. The out-of-memory bug touches how PHP escapes from allocation failures, while the stale-state bug implicates request cleanup across the runtime and extensions. Narrow configuration changes can block demonstrated paths, but not every possible producer and consumer of stale state. PHP therefore says updating is the only complete remediation.

The patched releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Older branches no longer receive upstream security releases, although PHP published minimal source backports for versions 7.4 through 8.1 and some distribution or long-term-support vendors provide their own packages. That leaves an operational gap: the systems most likely to be slow to upgrade are also the least likely to have a simple upstream update path.

The defender’s window was already closing

The public timeline shows how fragile coordinated disclosure becomes when many independent teams and vendors must prepare at once. The PHP Foundation says a 2024 external audit exposed the first signs of the out-of-memory problem, but work repeatedly stalled because proposed fixes risked compatibility breaks, denial-of-service behavior, or changes across third-party extensions. The Foundation calls that delay a structural failure caused by both consensus-based decision making and too few core developers with the required engine expertise.

The issue became urgent in 2026. Calif reported unconditional remote code execution on August 11 through OpenAI’s Patch the Planet program. Wiz independently found exploitable variants in August using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol; OpenAI and other auditors reported the same root cause and additional attack paths. Multiple teams then helped PHP validate the findings, test the eventual patch, and prepare cloud, hosting, firewall, and government guidance.

Coordination held until the final days. The two CVE identifiers began circulating on October 20, prompting PHP to announce the emergency release and move it forward by a day. A deleted proof-of-concept video revealed limited technical details. An embargoed distributor then published fixed container images more than six hours before the official release, giving anyone a binary diff while most users still lacked public packages.

AWS’s honeypot evidence makes the timeline more sobering. It observed one attempt from an anonymization network on October 17, before the public leak. Between 02:00 and 08:00 UTC on release day, it saw additional attempts from distinct infrastructure, suggesting multiple actors. After the 14:00 UTC disclosure, new proof-of-concept code appeared within hours and was used against sensors almost immediately.

The evidence does not establish that the October 17 attempt compromised a real server, nor does it reveal how the actor learned about the flaw. It may have been an independent discovery rather than an embargo leak. But either possibility defeats the comforting idea that the public advisory marks the start of exposure. For incident response, the relevant search window begins at the earliest observed exploitation, not the patch date.

AI compresses both sides of the race

The episode is unusually concrete evidence for an AI-driven shift in security economics. The vulnerable behavior had existed for more than a decade, and the PHP team had recognized part of the root problem in 2024 without producing a safe general fix. AI-assisted teams helped explore many configurations, construct working chains, find variants, validate patches, and coordinate a response. That is a real defensive gain.

It is not evidence that a model autonomously discovered and solved PHP2Shell. The reports describe combinations of frontier models, specialized tooling, expert researchers, maintainers, cloud providers, and months of coordination. The model vendors and security companies are also describing their own products, so their claims about which model made which decisive contribution should be read as self-reported.

The widely repeated claim that the bugs affected “70% of the internet” also needs qualification. PHP is used by a large share of websites, but usage statistics do not reveal which PHP version, server interface, configuration, network exposure, or vendor backport each site runs. The flaws are extraordinarily broad; a web-usage percentage is not a measured count of exploitable servers.

Even with those caveats, the operational lesson is clear. When public details arrive, attackers no longer need to wait for a small specialist group to hand them a finished exploit. Models can compare patches, explain unfamiliar code, generate test cases, and adapt memory layouts across targets. More actors can therefore move from disclosure to experimentation in hours.

For internet-facing critical software, patch service-level agreements should now be measured in hours, not seven or thirty days. Defenders should also retain behavioral telemetry that predates disclosure, because the first known exploit may be older than the first public warning. Coordinated disclosure remains necessary, but it is not a guaranteed head start. PHP2Shell shows that AI can enlarge the defender’s window by finding hidden flaws—and simultaneously make that window narrower once any useful detail escapes.