PHP2Shell: the investigation window starts before the patch
Amazon observed attack attempts before public disclosure. That changes the period defenders need to examine, without proving every targeted server was compromised.
Installing the PHP security update closes a vulnerability; it does not establish what happened before installation. Amazon’s threat-intelligence account of PHP2Shell reports an attack attempt against its MadPot sensors on October 17, four days before public disclosure. For administrators, the practical consequence is a longer investigation window than the advisory date alone would suggest.
The evidence needs a careful label. A honeypot is a monitored system intended to attract suspicious activity. An attempted exploit reaching one is evidence of an attempt, not proof that the same technique successfully compromised an ordinary production server. Amazon explicitly says the success of the early attempts on real-world systems remained unclear.
The patch and the investigation answer different questions
The PHP Foundation identifies the corrected releases as 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Its account describes two memory-state problems in error handling, including paths that can run before application code. Updating a content-management system alone therefore cannot be assumed to repair the interpreter underneath it.
Our earlier preparation guide focused on getting ready for the release. The new telemetry changes what a completed response should include. A clean deployment result is useful evidence about the software now running; it is not a retrospective health certificate.
Consider a server whose update finished on October 21. Searching only from that morning leaves the earlier period unexamined. The relevant timeline includes when the service was exposed, which workers handled traffic, and what logs still exist. Preserving those records matters because routine rotation can remove precisely the history needed to answer the question.
Why a request failing is not the whole story
The Foundation’s explanation places the flaws in memory management and error handling. These are parts of a runtime that applications ordinarily rely on to contain failure. If internal state remains inconsistent after an error, the effect can extend beyond the request that first triggered it.
That is why a generic assumption that an upload failed safely is insufficient. It also explains why a filter in front of a service is a different control from a corrected runtime. Our explanation of Cloudflare’s response firewall makes the same operational distinction: stopping a particular transaction does not repair the application behind it.
Amazon recommends examining web logs and unexpected process execution or file changes. Such signals need context. A deployment may legitimately change files; an unfamiliar address may belong to shared infrastructure. Treating either as automatic proof of intrusion risks obscuring the events that actually require investigation.
A release date is not a security boundary
PHP’s release announcement establishes that the corrected 8.5 version is available. The broader lesson of the chronology is narrower than claims that every PHP site was breached: defenders cannot use the public announcement as the earliest possible exposure date.
This applies equally to an Italian publisher, an international shop and a private business application. The organization running the service needs evidence about its own deployment, rather than a conclusion borrowed from a headline about the language.
The patch moves the system forward. The investigation has to look back far enough to make that progress trustworthy.
