News · 2026-10-23

AWS saw a PHP2Shell attempt four days before disclosure

AWS recorded a PHP2Shell exploitation attempt against a decoy system on October 17, four days before public disclosure. The finding puts pressure on a disclosure process already disrupted by leaked identifiers, an accidentally published demonstration and early fixed software images. It establishes an attempted attack before disclosure, without establishing a successful compromise or AI involvement in that attempt.

Key facts

• AWS dates the early attempt to October 17, four days before public disclosure.
• The PHP Foundation says fixed Chainguard images appeared at 07:41 UTC on October 21, ahead of the coordinated 14:00 release.
• The named sources are AWS’s threat-intelligence team and the PHP Foundation, which describe different parts of the timeline.
• Primary source: AWS’s MadPot telemetry report.

A patch can protect one organization while revealing useful information to an attacker. That tension runs through the PHP Foundation’s account of the release. Coordinated disclosure tries to give maintainers, distributors and users a usable window for preparing defenses. Once technical clues escape, the same coordination can leave some people waiting while others already possess a revealing update.

The earliest event in AWS’s account is separate from that public unraveling. Its MadPot decoy infrastructure received an exploitation attempt on October 17 from an address associated with a commercial anonymization network. AWS assessed that the actor likely possessed exploit information. The company does not know how the actor obtained it. A decoy is designed to attract suspicious activity; it supplies evidence about an attempted technique, rather than proof that ordinary production systems were compromised.

Public disclosure then fractured in stages. On October 20, Hacker News user petecooper posted a warning titled “Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming.” The original post named reserved vulnerability identifiers and expected timing, while acknowledging an unverified source. It did not publish technical exploitation details. The handle identifies the poster on the forum; the dossier does not establish a real-world identity.

The Foundation says circulating identifiers pushed it to announce earlier and bring the release forward from October 22 to October 21. An accidentally published demonstration video from Calif added another clue. Deleting a video cannot retrieve copies already made, so an accidental publication can continue shaping the attack timeline after the original disappears. In an October 22 apology, petecooper said the contact had said there was no embargo and expressed regret about the consequences.

The Foundation’s account places Chainguard’s fixed images more than six hours ahead of the coordinated release. A fixed image can function like a repaired lock placed beside its predecessor: comparing them helps reveal where the weakness was. This does not mean every patch instantly yields a working exploit. It explains why the timing of binaries matters even when nobody publishes a step-by-step attack.

Chainguard chief executive Dan Lorenc offered a different account, displayed on the company’s LinkedIn page. He said the company independently found the issue with its testing system and a frontier model, helped test fixes, and shipped after vendors shared evidence of exploitation attempts. He apologized for adding pressure to maintainers and said he believed the process allowed release once active exploitation was reported. The Foundation describes an embargo break; Lorenc describes a decision made in response to perceived immediate danger.

AWS also observed separate October 21 activity. It found public demonstration code from around 02:00 UTC and additional honeypot attempts between 02:00 and 08:00, before the 14:00 embargo lifted. Different payloads and infrastructure suggested multiple actors. AWS could not establish whether those attempts would have worked against real systems.

The AI connection is specific. Chainguard describes AI-assisted discovery, and AWS discusses how AI-assisted analysis can shorten the interval between a public fix and broader exploitation. Neither point establishes that AI caused the October 17 attempt. The earlier Ground Truth report on the PHP fixes supplies the release background; today’s development concerns the newly reported timeline and coordination failure.

The practical consequence is to treat patch distribution and disclosure as one operational problem. Maintainers need a process for deciding what changes when exploitation is suspected, and downstream operators need a way to move quickly once fixes become public. The honest limit is equally clear: this record shows early hostile activity and disagreement about release decisions. It does not identify the early attacker, prove a widespread pre-disclosure compromise, or demonstrate an AI-run attack campaign.

Primary source, verified: read the paper →

Ground Truth. (2026, October 23). AWS saw a PHP2Shell attempt four days before disclosure. Ground Truth. https://groundtruth.day/news/aws-saw-php2shell-attempt-four-days-before-disclosure.html

@misc{groundtruth:aws-saw-php2shell-attempt-four-days-before-disclosure,
  title  = {AWS saw a PHP2Shell attempt four days before disclosure},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {oct},
  url    = {https://groundtruth.day/news/aws-saw-php2shell-attempt-four-days-before-disclosure.html}
}

Topics: cybersecurity · vulnerabilities · ai-security · disclosure · php