PHP2Shell attack attempts began before disclosure—what must operators do now?

Update PHP now; a firewall is only a temporary layer

The PHP project has released fixes for two critical vulnerabilities that can let an unauthenticated attacker execute code on a server. The fixed branches are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP says partial workarounds exist, but updating is the only complete protection. PHP 8.1 and earlier no longer receive normal project updates; operators should obtain a supported distribution backport or move to a supported release.

The UK National Cyber Security Centre tells organisations to inventory every PHP installation, apply the fixed build or verified supplier package, confirm the update succeeded and monitor for signs of compromise. That sequence matters for managed hosting and appliances too: a website owner may not control PHP directly, but should still obtain a dated confirmation from the provider rather than assume a platform label means the runtime is patched.[1][6]

Attack attempts were visible before public disclosure

Amazon Threat Intelligence says its MadPot honeypot recorded an exploitation attempt on 17 October, four days before the vulnerabilities were publicly disclosed. It then observed proof-of-concept material and further attempts on 21 October. The company says the earliest attempt came from infrastructure associated with a commercial anonymisation service, but it does not know how the actor obtained the exploit information. That uncertainty is important: the telemetry supports early hostile interest, not a claim about the identity or success of an attacker.

Cloudflare separately reports exploitation attempts and mutated payloads, and says it deployed managed protections before disclosure. The flaws affect PHP's core request handling rather than one application framework. Exposure still depends on version, configuration and reachable paths, so PHP's large footprint should not be read as a count of vulnerable servers. Defenders should review internet-facing hosts, containers, appliances and managed services separately and preserve logs where compromise is suspected.[2][3][5]

AI accelerated discovery, not the evidence standard

OpenAI says its research system identified one flaw while Wiz independently found the vulnerability family, followed by human verification and coordinated disclosure. That is consequential evidence that AI can accelerate exploration of complex code. It is not proof that an autonomous system safely completed the investigation, and the operational record now shows why disclosure discipline matters: exploit attempts may begin before defenders have complete public guidance. The assessment should change only with reliable patch-coverage, exploitation and confirmed-compromise data.[3][4]