Amazon reports PHP2Shell attempts before public disclosure

What the Amazon report establishes

In its October 21 report, Amazon identifies the following sequence:

• An exploitation attempt reached MadPot on October 17.
• Further attempts arrived between 02:00 and 08:00 UTC on October 21.
• Additional public exploit demonstrations appeared after the 14:00 UTC disclosure, followed by traffic to its sensors.

Amazon says it does not know whether those attempts would have succeeded on real systems. It also leaves unresolved how the earlier actor obtained the information. The report gives no total of successfully compromised customer servers.

For an administrator, the reported date is a reason to review retained records from before disclosure. It is not a diagnosis of any particular website. Preserve the date when your server received the fixed package and when its PHP service began running it; those define the period that needs attention on that server.

Controlled demonstrations answer a different question

Wiz’s research describes successful code execution in WordPress, Drupal and Joomla demonstrations, along with reading sensitive PHP process memory. Such demonstrations establish that attacks can work under the tested conditions. They do not identify a production customer compromised through the same path.

PHP’s advisories distinguish the web-server setup and application behavior. The out-of-memory advisory describes a demonstrated attack before application code runs when PHP is loaded as Apache’s mod_php module. The advisory also describes application-level paths that can affect PHP-FPM, which runs separate PHP worker processes. The stale-state advisory describes data left over between requests handled by the same worker. Neither supports declaring a server safe solely because it uses PHP-FPM.

The PHP Foundation’s release account says public circulation of the CVE identifiers on October 20 prompted an earlier release. It records a disclosure process that changed during the incident, rather than a single date from which every operator can assume exposure began.

Review the period before your update

JPCERT/CC’s October 22 advisory recommends checking suspicious web requests, abnormal session-cookie responses, memory errors and unexpected PHP worker restarts. It also calls for reviewing unusual processes, connections and file creation. If compromise is suspected, preserve relevant records before investigating scope and isolating the affected system.

A useful review combines web-server, PHP, operating-system and hosting records. Note gaps in retention and whether response cookies or request details were logged at all. Do not turn an absent record into a negative finding.

Datadog’s laboratory test illustrates why status codes alone are weak evidence: its refined demonstration returned HTTP 200 while the same worker continued running. Review activity around requests, not just a list of error responses.

Successful memory access can expose credentials available to PHP. If an investigation finds that secrets were exposed, include their replacement and access review in recovery. Apply the fixed PHP package as well; changing a password does not repair the runtime flaw.

Sources and verification note

Primary reporting was rechecked on October 23. The research and investigation sources above describe different kinds of evidence, so their observations have not been combined into a victim total.

The related early-traffic report compares other companies’ dated sensor observations.

Next: use the PHP2Shell check-and-verify guide to confirm the running fix and record anything that still needs an incident review.