PHP2Shell Attack Timeline: What Happened and Who Reported It?
Follow the October 17–22 reports of early attacks, successful exploitation and precautionary outages—and why downtime is not proof of a breach.
The short answer
The timeline distinguishes Amazon honeypot attack attempts, successful exploitation reported by Sophos and precautionary website outages. These reports do not establish that every offline website was hacked or identify a definitive list of named victims whose data was stolen.
Follow the October 17–22 reports of early attacks, successful exploitation and precautionary outages—and why downtime is not proof of a breach.
01 / The story
Attempts, exploitation and outages are different events
The PHP2Shell story moved quickly from a privately handled security issue to active exploitation attempts. The most important distinction is that researchers observed attacks against security monitoring systems and reported successful exploitation, but that does not mean every organization whose website went offline was hacked.
02 / The story
October 17, 2026: Amazon detects an early exploitation attempt
Amazon Threat Intelligence reported detecting a PHP2Shell exploitation attempt on October 17 through MadPot, its network of honeypots designed to attract and study malicious activity.
The attempt occurred four days before the vulnerabilities were publicly disclosed. Amazon said the source IP address was associated with a commercial anonymization network. That made it harder to identify who was behind the activity, and Amazon said it remained unclear how the actor obtained information about the vulnerability before its public release.
A honeypot is a monitored system designed to attract suspicious activity. An attack against one can provide valuable evidence about attacker behavior, but it does not establish that a real customer website was compromised. [1]
03 / The story
October 20: Details leak before the planned disclosure
Details of the two PHP vulnerabilities appeared online before the coordinated public disclosure. Security researchers and defenders began responding to the leak while the PHP maintainers prepared security releases.
Elastic Security Labs reported that the information leaked on October 20 and that the PHP security team moved its emergency release schedule to October 21 at 14:00 UTC.
The leak created a serious problem: defenders had less time to prepare, while people with access to the technical details could potentially develop or adapt exploit code before every affected server had been updated. [2] [1]
04 / The story
October 21: Security fixes become public
The PHP project released fixed versions on October 21. Amazon reported observing multiple proof-of-concept exploits and further attempts against its honeypots around the disclosure period.
Amazon's telemetry showed different payloads and anonymization infrastructure, suggesting that multiple actors were attempting to exploit the issue. However, the company said its analysis was ongoing and that it was not yet clear whether every observed attempt would have succeeded against real-world systems.
OpenAI also published details of its coordinated security response. It said a critical PHP flaw was identified by its research initiative with AI assistance, while Wiz independently discovered and reported both vulnerabilities. The PHP maintainers led the fixes, with security partners helping prepare protections. [1] [3] [4]
05 / The story
October 22: Sophos reports successful exploitation
In its October 22 update, Sophos reported multiple PHP2Shell-related exploit attempts and one successful exploitation in the activity observed by its threat hunters. The post was first published October 21; the finding here is scoped to its later update. [5]
Its technical analysis described activity involving a payload that appeared to be a Mirai variant called potassium. The observed activity included a file written to a temporary directory and executed on the affected system.
Sophos also stated that it had not observed evidence linking the activity to ransomware deployment, data theft, or supply-chain compromise at the time of its report.
This is stronger evidence than a blocked scan or an attempt against a honeypot: Sophos reported a successful exploitation event. However, its public report did not identify a named customer organization whose website or data was compromised. The finding should not be turned into a claim that a particular company was hacked. [5]
06 / The story
Which Organizations Were Hacked?
As of October 22, 2026, public reporting identifies organizations that detected attack attempts, reported successful exploitation, or temporarily took services offline. These are different categories and should not be presented as interchangeable. [6] [1] [5]
| Organization or source | What was publicly reported | Does it confirm a named victim was hacked? |
|---|---|---|
| Amazon Threat Intelligence | An exploitation attempt against its MadPot honeypot on October 17, followed by more attempts around public disclosure. | No. These reports concern honeypot telemetry, not confirmation that an Amazon customer website was breached. |
| Sophos | Multiple related attempts and one successful exploitation in its threat-hunting observations. | Successful exploitation was reported, but the public report did not name the affected organization. |
| UK government services | The Guardian reported that 32 government services had been taken offline, largely as a precaution while updates were applied. | No. The UK government said this did not mean those services had been hacked. |
07 / The story
Why were websites taken offline if they had not been hacked?
A security team does not have to wait for a confirmed breach before taking action. If a vulnerable system is publicly accessible and a working exploit is circulating, temporarily restricting access may reduce the risk while administrators install a fix.
That appears to explain much of the reported UK government downtime. The Guardian reported that services were taken offline largely as a precaution while updates were applied, and the UK government said the disruption did not mean those services had been hacked.
This distinction is important for readers: a website being offline, an attack being attempted, a vulnerability being exploited, and data being stolen are four different events. [6]
08 / The story
What did the attackers actually do?
The public technical reporting provides a clearer picture of the observed activity than it does of the identities of the attackers.
1. They targeted vulnerable PHP installations. The flaws affect PHP's request-handling and memory-management behavior. Depending on the server architecture and configuration, a specially crafted request could trigger the vulnerable behavior without an authenticated account.
2. They attempted to turn the flaw into code execution. Remote code execution can allow malicious commands or programs to run under the permissions of the affected service.
3. Some activity attempted to install malware. Sophos reported a successful exploitation event involving a payload that appeared to be a Mirai variant. Mirai-related malware is commonly associated with taking control of devices for botnet activity, although the observed report should not be generalized to every PHP2Shell attempt.
4. Researchers observed different attack sources and payloads. Amazon reported varied payloads and anonymization infrastructure. That suggests multiple actors were active, but it does not establish the real-world identities of those actors or prove that every attempt resulted in a compromise.
5. The full impact remained uncertain. Sophos had not observed evidence connecting the activity it analyzed to ransomware, data theft, or supply-chain compromise as of its October 22 update. Other investigations could reach different conclusions as more evidence becomes available. [4] [2] [5]
09 / The story
What should website owners do after these reports?
Organizations should not rely on a list of publicly named victims to decide whether they need to act. A vulnerable server may be at risk even if no breach has been publicly disclosed.
The Canadian Centre for Cyber Security recommends immediate patching. The checks below are general defensive recommendations, not a claim that its alert documents every step or that Qlauson investigated a compromised host. [4]
- Update affected PHP installations to an appropriate fixed release.
- Check PHP versions bundled into containers, appliances, hosting environments and third-party applications.
- Review web-server, application, authentication and endpoint logs for suspicious activity.
- Investigate unexpected processes, unfamiliar files, new accounts or unusual outbound connections.
- If compromise is suspected, preserve relevant evidence and involve a qualified incident-response professional.
- Rotate exposed credentials and restore affected systems through a controlled recovery process if a breach is confirmed.
010 / The story
The bottom line
PHP2Shell has generated reports of early exploitation attempts, successful exploitation observed by a security vendor, emergency patching, and precautionary website outages. Those developments are serious, but they do not justify claiming that every affected or offline website was hacked.
As of October 22, 2026, the public sources cited here do not establish a definitive list of named organizations whose customer data was stolen specifically through PHP2Shell. That may change as investigations continue. Qlauson will distinguish confirmed compromises from attack attempts and precautionary shutdowns rather than present unverified victim claims as facts.
For version-specific guidance, read our PHP2Shell security patching guide.
A closer look
Qlauson Team: timeline and evidence limits
This article organizes the supplied October 22 timeline by report date, then separates attack observations, reported exploitation and outages. We cross-checked accessible source search excerpts on October 22, 2026; full-page passages were not all accessible. We removed an uncorroborated alert count and specific named-site outage claims rather than present them as verified. Qlauson did not reproduce an exploit or inspect affected systems.
This is defensive educational reporting, not a forensic finding, incident-response service or legal advice. Investigations may change the public picture. The artwork is an original conceptual illustration, not evidence of an actual incident. For version-specific fixes, see our separate PHP2Shell patching guide.
Put it to work
Separate evidence from assumptions
When reading a security incident report:
0 of 5 considered
These questions are editorial guidance, not a product score or verified assessment.
Keep learning
Further reading
- PHP2Shell: Which PHP Versions Need Security Patches?
Qlauson · Cybersecurity
- AI Agent Security: Is Computer Access Safe?
Qlauson · Cybersecurity
- Amazon Threat Intelligence — early exploitation in MadPot
External resource · Honeypot observations do not establish a customer breach. Opens in a new tab.
- Elastic Security Labs — PHP2Shell analysis
Primary documentation · Leak and emergency release timeline. Checked Oct 22, 2026. Opens in a new tab.
- OpenAI — coordinated disclosure
Primary documentation · Participant account of AI-assisted discovery and coordinated response. Checked Oct 22, 2026. Opens in a new tab.
- Canadian Centre for Cyber Security — PHP alert
Primary documentation · Defensive patching and investigation guidance. Checked Oct 22, 2026. Opens in a new tab.
- Sophos — exploitation observations
Primary documentation · Reported successful exploitation does not identify a named victim. Checked Oct 22, 2026. Opens in a new tab.
- The Guardian — attacks and precautionary outages
Primary documentation · Secondary reporting distinguishes temporary downtime from confirmed compromise. Checked Oct 22, 2026. Opens in a new tab.
Read next
Should AI Agents Move Money? Permissions, Approvals and Audit Trails
Before AI agents move business money, separate payment drafting from release, bind approvals to exact details, set limits and keep an audit trail.
Continue reading
