Attackers were probing for PHP2Shell four days before anyone outside the embargo circle could legally discuss it. Amazon Threat Intelligence says its honeypot network recorded an exploitation attempt on October 17, 2026, and The Register reported on October 22 that hackers have since piled on.
The attempt hit MadPot, Amazon’s honeypot and telemetry network, from an IP address tied to a commercial anonymization network, according to the AWS Security Blog. PHP2Shell is the shorthand for two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Amazon says it still cannot explain how the actor got exploit information before disclosure.
That gap is the real story. The bugs themselves already drew heavy attention, and our earlier report on how the flaw surfaced covered the scale of the exposure. This piece looks at what the October 17 timestamp changes: for incident responders, for embargo practice, and for every team that treated October 21 as day zero.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Amazon Threat Intelligence Saw in MadPot
MadPot is a deliberately exposed set of systems built to attract attackers and record what they do. Amazon Threat Intelligence uses its telemetry to spot new exploitation patterns early. On October 17, 2026, that telemetry caught a PHP2Shell exploitation attempt against the network.
The source IP belonged to a commercial anonymization network. That detail limits what investigators can say. Anonymization services hide the true origin of traffic by design, so the address tells Amazon how the traffic was routed and not who sent it. The company said the activity suggested a threat actor was behind it.
Two limits matter here. Amazon has not confirmed whether the October 17 attempt would have compromised a real-world PHP server. A honeypot records intent and technique, but it cannot prove the payload would have worked against a production host. Nobody has publicly identified the sender either. Treat the October 17 event as a confirmed early signal, not as proof of a successful breach anywhere.
PHP2Shell Timeline: From First Report to Mass Exploitation
The sequence below combines dates from Sophos, Amazon Threat Intelligence and the AWS write-up. Read it as a compressed view of roughly ten weeks of quiet followed by a very loud day.
| Date and time | Event | Attributed to |
|---|---|---|
| August 11, 2026 | PHP Project receives its first reports of the issues | Sophos |
| October 17, 2026 | MadPot records a PHP2Shell exploitation attempt from an anonymized IP | Amazon Threat Intelligence |
| October 21, 2026, about 02:00 UTC | Earliest proof-of-concept exploit appears, about 12 hours before the embargo ends | Amazon Threat Intelligence |
| October 21, 2026, 02:00 to 08:00 UTC | More attempts arrive from additional anonymized infrastructure | Amazon Threat Intelligence |
| October 21, 2026, 14:00 UTC | Scheduled end of the PHP embargo | Amazon Threat Intelligence |
| October 22, 2026 | Amazon describes PHP2Shell as broadly exploited in the wild | The Register, Amazon Threat Intelligence |
From August 11 to October 21 is 71 days. For most of that stretch the flaws sat inside a small circle of maintainers and coordinators. The first outside evidence of exploitation arrived with four days to spare.
Why Four Days Before Disclosure Changes the Math
Most patch programs measure risk from the day a vendor publishes a fix. Teams set service-level targets from that date, and auditors check against it. If exploitation started on October 17, every one of those clocks started late.
Consider a typical response plan for a critical web-server bug. It says to patch within a fixed window after the advisory, then review logs for signs of compromise after the patch date. A team that followed that plan to the letter on PHP2Shell would have looked at logs from October 21 onward. The earliest known attack sits four days earlier. Anything that landed between October 17 and the patch would sit outside the review window.
Amazon’s CISO, CJ Moses, framed the lesson the same way. According to FourWeekMBA’s coverage of the AWS findings, he advised starting investigations from the earliest known exploitation and not from the disclosure date. For PHP2Shell, he said, that means going back to at least October 17.
Verbatim: What AWS Said
Amazon’s own wording carries more weight than any paraphrase, so here are the exact statements from the record. The AWS Security Blog post says: “Amazon Threat Intelligence identified a PHP2Shell exploitation attempt dating to Oct. 17, 2026, in MadPot telemetry, four days before public disclosure of CVE-2026-109618 and CVE-2026-109619.”
CJ Moses, Chief Information Security Officer at AWS, described the attribution problem in the same post: “While the vulnerability was under embargo, the targeting of a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor, though it remains unclear how the actor acquired exploit information prior to disclosure.”
On the post-embargo surge, SecurityWeek quotes Amazon Threat Intelligence: “Once the embargo was lifted and the patch was released, additional proof-of-concept exploits appeared within hours, and we saw them used against our sensors almost immediately.” The same coverage carries the summary line, “PHP2Shell is now being broadly exploited in the wild.”
Read together, the four statements draw a careful line. Amazon states what it measured. It says what the measurement suggests. It admits what it does not know. Few vendor disclosures draw that line so cleanly, and it is worth copying when you write your own internal incident notes.
How Could Exploit Details Exist Before Disclosure?
Amazon has not answered this question, and neither has anyone else on the record. What follows is our analysis of the general categories, not a claim about what happened here.
Independent discovery is the simplest explanation. Researchers and attackers sometimes find the same bug without talking to each other, especially in widely audited code. A second possibility is a leak from somewhere inside the coordination chain. Embargoed details pass through maintainers, reporters, distributors and downstream vendors, and every extra mailbox is an extra place for information to slip. A third is reverse engineering of early fixes in a downstream build or a pre-release branch.
Each of these leaves a different fingerprint, and none has been demonstrated. The honest position is the one Amazon took: the activity looks like a threat actor, and the origin of their knowledge is open. Anyone who tells you otherwise is guessing.
Confirmed, Reported and Unconfirmed: A Fact Check
Fast-moving vulnerability stories collect claims quickly, and some of them harden into fact through repetition. This table separates what the named sources established from what remains open.
| Claim | Status | Source |
|---|---|---|
| PHP2Shell covers CVE-2026-109618 and CVE-2026-109619 | Confirmed | AWS, Sophos |
| Exploitation attempt on MadPot on October 17, 2026 | Confirmed by Amazon | Amazon Threat Intelligence |
| Rated CVSS v4.0 9.2 (Critical), unauthenticated remote code execution | Rating published | Sophos |
| Multiple attackers after the embargo, not one confirmed group | Reported by Amazon | Amazon Threat Intelligence |
| The October 17 attempt would have compromised a real server | Unconfirmed | None |
| How the actor obtained exploit information early | Unconfirmed | Amazon says it is unclear |
| Identity or affiliation of the attackers | Unconfirmed | None |
The Technical Stakes: Unauthenticated Code Execution at CVSS 9.2
Sophos describes the PHP vulnerabilities as allowing unauthenticated remote code execution with the privileges of the web-server account, and it rates them CVSS v4.0 9.2 (Critical). Unauthenticated means the attacker needs no login, no stolen password and no prior foothold. Code execution as the web-server account means the attacker can run commands as whatever user the site runs under.
That account usually has enough reach to hurt. It can read application source and configuration files, which often hold database credentials and API keys. It can write to upload directories, which is how web shells get planted. The pattern is familiar from other recent cases. Our coverage of the Nextcloud flaw that left web shells behind shows what the aftermath looks like once an attacker gets in through a similar door.
PHP also runs at a scale few runtimes match. A flaw in the core language, as opposed to a single plugin or framework, reaches shared hosting, content management systems, custom business apps and legacy intranets alike. The Cyber Security Agency of Singapore treated the issue as serious enough to publish alert AL-2026-151, titled Critical Vulnerabilities in PHP (PHP2Shell). CNN’s headline went further and said the issue forced websites to shut down, a line that matches Malwarebytes reporting on sites going offline for emergency security updates.
After the Embargo: Hackers Pile On
The second act started before the embargo formally ended. Amazon Threat Intelligence detected multiple proof-of-concept exploits on October 21, the earliest at roughly 02:00 UTC. That is about 12 hours before the scheduled 14:00 UTC lift. Between 02:00 and 08:00 UTC, further attempts arrived from additional anonymized infrastructure.
SecurityWeek’s report on the patch release framed it as the first exploitation attempts hitting sensors as fixes landed. Amazon said the activity involved multiple attackers and not one confirmed group. That fits the usual pattern. Once a working proof of concept circulates, the cost of attacking drops to near zero, and opportunistic scanners follow within hours.
The speed is no accident. Attackers now watch advisories, commit logs and patch diffs in near real time, and some use automation to turn them into scanners. Our look at an AI agent hacker that breached more than 100 firms shows how far that automation has come. A bug with a CVSS 9.2 score and no authentication requirement is the ideal target for that kind of tooling.
Government and Vendor Response
Response came fast on both sides of the public and private line. Help Net Security published its patch-now story on October 21, titled PHP2Shell: Critical PHP vulnerabilities patched, update now. Sophos issued a security advisory the same day, and Malwarebytes explained why sites were going dark for emergency maintenance. Singapore’s national cyber agency issued its alert.
We reported separately on an NSA warning that came as four nations pulled sites offline. That earlier coverage covers the government side in more detail. What the AWS finding adds is a reason for those agencies to push their guidance back in time, because the safe assumption now is that exploitation predates the public patch.
Coverage Compared: Who Contributed What
No single outlet or vendor holds the full picture. Each contributed a different layer, and the layers together explain why the story moved so quickly across the industry.
| Source | What it added | Layer |
|---|---|---|
| AWS Security Blog | MadPot telemetry showing the October 17 attempt | Primary detection |
| Sophos | CVSS v4.0 9.2 rating and the August 11 first-report date | Severity and history |
| SecurityWeek | Patches landing as first attempts hit sensors | Trade reporting |
| Help Net Security | Patch-now guidance published October 21 | Practitioner alert |
| Malwarebytes | Why websites went offline for emergency updates | Operational impact |
| Cyber Security Agency of Singapore | Alert AL-2026-151 on the PHP vulnerabilities | Government advisory |
| CNN | Mainstream framing of the AI-found issue and site shutdowns | Public awareness |
| The Register | October 22 report that attackers piled on after AWS revealed the early attempt | Synthesis |
Honeypot telemetry is the only layer that can show an attack before a patch exists. Advisories, news and agency alerts all depend on public disclosure to start their own clocks. That asymmetry is why MadPot-style networks deserve a seat in your threat intelligence mix, a point we explore in our guide to the best threat intelligence platforms for security teams.
Historical Context: Embargo Leaks Are Not New
Security history includes several cases where exploitation was seen close to, or before, public disclosure. Log4Shell in December 2021 went from disclosure to mass scanning within days. The 2021 ProxyLogon campaign against Exchange servers saw intrusions that predated the patch. In both cases defenders learned late that the safe window was shorter than the advisory implied.
PHP2Shell differs in one respect. The earliest signal comes from a vendor-run honeypot with a precise date, which gives defenders something concrete to work from. Many past cases relied on retrospective log hunting, with fuzzy start dates and argument over which intrusions belonged to the campaign. A clean October 17 marker shortens that argument.
The recurring lesson is that embargoes buy time but never guarantee secrecy. Coordinated disclosure remains the best available system for getting fixes out before attacks scale. The AWS finding does not break that system, but it does show how thin the protection is when a bug is this valuable. Our write-up of the Plex2Shell vulnerabilities that hit servers within 24 hours tells a similar story of compressed timelines.
Market Impact: Hosting, Security Vendors and Cloud Providers
We have no verified financial figures tied to PHP2Shell, so this section deals in direction and not in dollars. The effects land in three places.
Hosting providers carry the most immediate operational load. Shared hosts run thousands of customer sites on a single PHP build, so one update can protect or expose a huge customer base. Providers that patch centrally gain a reputational edge, while those that leave updates to customers will field support tickets for weeks. The Malwarebytes report of sites going offline suggests many operators chose downtime over risk.
Security vendors gain a case study. Amazon used its own telemetry to publish a finding that no patch-focused competitor could replicate, and that is a marketing asset as well as a technical one. Expect rivals to point to their own sensor networks in coming sales pitches. Cloud providers, meanwhile, face pressure to offer managed virtual patching, since customers on locked-down stacks cannot always update on short notice.
What Defenders Should Do Now
The advice follows the AWS finding directly. Patch first, then hunt backward from the earliest known date, not from the patch date.
Patch and verify
Apply the fixed PHP release from your vendor or distribution, then confirm the running version, not just the installed package. Containers and long-lived PHP-FPM workers often keep serving the old binary until restarted. If a patched package for your branch does not exist yet, isolate the service or pull it offline until one does.
Hunt from October 17
Review web-server and application logs from October 17 forward. Look for unexpected new files in web-writable directories, unusual child processes spawned by the web-server account, and outbound connections from hosts that normally make none. The command below pulls access-log lines for the relevant days on a typical Nginx host.
php -v
zgrep -h -E '\[(17|18|19|20|21|22)/Oct/2026' /var/log/nginx/access.log* | less
find /var/www -type f -newermt '2026-10-17' -name '*.php' -lsTreat stopgaps as stopgaps
Interim configuration changes and web application firewall rules can cut exposure, but they do not replace the fix. Attackers adapt payloads quickly, and a rule written for the first proof of concept may miss the third. Keep them in place until the patch is verified, then keep monitoring anyway. For teams weighing tooling to automate this triage, our Tenable vs Qualys vs Rapid7 pricing comparison covers three common scanner options. More analysis sits in our cybersecurity section.
Five Predictions for the Weeks Ahead
These are our assessments, built on the pattern of earlier incidents and not on any statement from the named sources.
- More vendors will report early activity. If one honeypot network caught an October 17 attempt, others with similar coverage will check their own records. Expect at least one more telemetry-based report.
- Embargo handling will draw scrutiny. Coordinators and maintainers will face questions about who held the details and for how long. A formal review of distribution lists is a reasonable outcome.
- Scanning will stay elevated. Unauthenticated code execution in a core runtime keeps attackers interested for months. Sites that skip the update will be found.
- Hosts will push forced updates. After this week’s downtime, providers will move toward automatic patching defaults for customers who never opt in.
- Detection dates will enter compliance language. Auditors and cyber insurers will start asking for investigation windows tied to earliest known exploitation, not to advisory dates.
Bottom Line for Security Teams
The takeaway: the disclosure date is a legal and logistical milestone, not a safety boundary. Amazon Threat Intelligence showed that a threat actor was probing for PHP2Shell on October 17, 2026, and that many more joined within hours of the embargo lifting. Patch fast. Hunt backward. Write your incident notes so that they say what you measured, what it suggests and what you still do not know, the same way Amazon did.
Frequently Asked Questions
What is PHP2Shell?
PHP2Shell is the name for two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Sophos says they allow unauthenticated remote code execution with the privileges of the web-server account and rates them CVSS v4.0 9.2 (Critical).
When did attacks on PHP2Shell begin?
Amazon Threat Intelligence detected an exploitation attempt on October 17, 2026, four days before public disclosure. More proof-of-concept exploits appeared on October 21, the earliest at about 02:00 UTC.
How did AWS spot the attack?
The attempt targeted MadPot, Amazon’s honeypot and telemetry network. The traffic came from an IP address associated with a commercial anonymization network.
Who is behind the attacks?
Nobody has said. Amazon described multiple attackers rather than one confirmed group, and the identities or affiliations of the attackers remain unconfirmed.
How did the attacker get exploit details before disclosure?
Unknown. Amazon says it remains unclear how the actor acquired exploit information prior to disclosure. We have not seen any named source confirm a cause.
Would the October 17 attempt have worked on a real server?
That is unconfirmed. A honeypot records the attempt, but the reporting does not establish whether it would have compromised a production PHP server.
Which date should incident responders use for log review?
Start at October 17, 2026, the earliest known exploitation, and not at the October 21 disclosure. Treat any earlier compromise signs as possible until your logs rule them out.
