- AWS says one of its honeypots logged an attempt to exploit the PHP2Shell flaws on October 17, four days before the public fix on October 21.
- How the actor got its information is unclear, and AWS does not know whether the attempts would have worked against real systems.
- Leaders should ask whether their teams can list every PHP system, patch within hours, and search logs from before a disclosure date.
A fix is not always the first move
The usual mental model is the disclose-then-patch sequence. A flaw is announced, a fix ships, and defenders race to apply it. One case from Amazon Web Services (AWS) shows that the order can differ.
The case is PHP2Shell, the label for two vulnerabilities in PHP. Wired describes them as critical, and PHP is a widely used language for building websites and apps. Wired reports that AWS saw an exploitation attempt on October 17. The public disclosure came four days later, on Wednesday, October 21.
The lesson here is narrow but useful. For this flaw, the clock appears to have started before the advisory did.
What AWS saw
AWS runs honeypots. These are deliberately vulnerable servers that attract attackers so researchers can study them. On Wednesday, analysts reviewed older honeypot activity and found the October 17 attempt.
It came from an IP address that AWS links to a "commercial anonymization network", meaning a proxy network or VPN. AWS chief information security officer CJ Moses wrote that this suggests a threat actor. He also wrote that it "remains unclear how the actor acquired exploit information prior to disclosure."
More followed. In the hours before the 10 am ET disclosure, AWS says its honeypots received several more attempts. They used different anonymizing providers and seemed to pursue different goals. AWS says this likely points to several actors.
After disclosure, Moses wrote that PHP2Shell is "now being broadly exploited in the wild." Proof-of-concept exploits, which are working demonstrations of an attack, also began to appear publicly on Wednesday. Some seemed to surface hours before the announcement.
Wired adds that some governments and other groups took key websites offline ahead of the release. That way, the sites could not be targeted before patches were ready.
How a patch becomes an exploit
A software fix also describes the flaw. Comparing the old code with the new code, known as a patch diff, shows what changed. That points to where the weakness was.
Moses argued that this shortcut is getting easier to use. Exploitation used to follow the release of a public proof of concept. A handful of skilled people wrote the attack tools, and everyone else waited for them. He wrote that this dependence is weakening.
AWS's explanation is that AI-assisted analysis lowers the cost of turning a diff or advisory into an attack that works. So more actors can move within hours or even minutes after technical details come out.
That explains speed after disclosure. It does not explain October 17. Nobody has said how the earlier actor got its information.
What is still unknown
The limits matter. Moses said technical analysis is ongoing. He also said it is unclear whether any of the attempts would have worked against real-world systems. A honeypot hit shows intent and timing, not a confirmed breach.
Wired's report does not say how many organisations were compromised. The PHP Foundation had not responded to Wired's request for comment. One honeypot, one early actor and one set of flaws is a single case. It does not establish a trend.
Who carries the cost
The people at the sharp end are administrators and security staff. Wired describes them racing to find and patch vulnerable sites and apps once the fixes landed. Some organisations chose to take sites down instead.
Those teams cannot fix what they have not mapped. The same goes for software and hosting that a supplier maintains on your behalf. In that case, the supplier's speed matters as much as your own.
Questions to put to your team
First, can we list every system that runs PHP, including software and hosting supplied by vendors? Second, how fast can we apply an emergency fix, measured in hours rather than weeks?
Third, do our logs reach back before the disclosure date? AWS found this attempt by looking back at earlier honeypot activity. Teams with very short log retention would struggle to do the same.
Fourth, who is authorised to take a site offline, and on what evidence? Some governments and other groups made that call before the release. It is easier to make with a plan than without one.
Wired's report names no affected versions or CVE identifiers. Check your vendors' advisories for those details.
In this case, the public announcement was not the first moment anyone had the flaw in their sights.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Wired.
