New evidence changes the timeline of the PHP security emergency. WIRED reports that attack attempts preceded the October 21 public disclosure. The development is distinct from the release of patches: it concerns what defenders may need to investigate before that release date.
A patch can close a vulnerable path going forward. It cannot, by itself, establish what happened while that path was open. That distinction makes the newly reported chronology operationally important without proving that every vulnerable system was compromised.
An earlier attempt, with important limits
In its October 21 research post, Amazon Threat Intelligence says MadPot honeypot telemetry contains a PHP2Shell exploitation attempt from October 17, four days before disclosure. AWS associates the source address with commercial anonymization infrastructure and says it does not know how the actor obtained exploit information.
AWS also reports multiple attempts before the October 21, 14:00 UTC disclosure, with differing payloads and infrastructure. It explicitly leaves open whether those attempts would have succeeded against real-world systems. Separately, it says exploitation is now widespread. An observed attempt, a successful compromise and a claim about current activity are different levels of evidence.
The earliest observation should consequently be treated as an investigative starting point, not a universal infection date. A honeypot gives researchers visibility into activity reaching that sensor. It does not provide a complete census of all attackers, all targets or the first time anyone discovered a flaw. The uncertainty is part of the finding, not a reason to replace it with a stronger claim.
The maintainers describe a disrupted release
The PHP Foundation’s original account says the fixes shipped in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It describes two critical vulnerabilities affecting memory management and error handling, and says early signs of one underlying problem had been identified in 2024. The difficulty was not simply finding a suspicious code path; choosing a compatible, workable repair also consumed scarce specialist effort.
The Foundation says circulating CVE identifiers prompted it to advance the planned release by a day. It also describes a mistakenly published demonstration video and an early distributor release. Those events belong to its account of disrupted coordination. They should not be presented as an established explanation for AWS’s October 17 observation, which predates them.
This separation avoids an easy but unsupported causal story. Evidence that details circulated before a scheduled announcement does not identify how every earlier actor learned about a bug. Attribution would require evidence connecting the specific activity to a specific information source. Neither publication supplies that connection for the October 17 attempt.
AI changes urgency, not the burden of proof
AWS argues that AI-assisted analysis is reducing the time needed to turn disclosed technical changes into exploits. That is its assessment of the broader threat environment, not proof that AI produced the particular October 17 attempt. Its guidance emphasizes urgent upgrades, investigation extending back to the earliest known activity, and detection beyond signatures for individual CVEs. Source: AWS research and defensive guidance.
For a response team, the resulting work has two tracks. One is verifying that affected software has received an appropriate fix. The other is assessing evidence of earlier intrusion. Completing the first track should not be recorded as completion of the second, because the questions and supporting evidence are different. A status report should make clear whether it records a deployed update, a completed investigation, or both.
The immediate editorial correction is equally clear: an absence of publicly reported exploitation at disclosure was not a guarantee that attacks had not happened. The new telemetry narrows that uncertainty, while leaving the origin and real-world success of the earliest attempt unresolved.