Amazon Traced PHP2Shell Exploitation to Oct 17, Four Days Before CVE-2026-109618 Disclosure
Amazon Threat Intelligence reported that it observed a PHP2Shell exploitation attempt on Oct. 17, 2026, four days before CVE-2026-109618 and CVE-2026-109619 were publicly disclosed on Oct. 21, 2026. The finding means defenders should measure their response window from the earliest known exploitation, not from the advisory date, and that critical internet-facing patches should be treated as an hours-scale problem rather than a 7-day or 30-day one.
What Amazon actually detected
Amazon Threat Intelligence identified a PHP2Shell exploitation attempt against its MadPot honeypot network dated to Oct. 17, 2026, four days before public disclosure of CVE-2026-109618 and CVE-2026-109619. The attempt originated from an IP address associated with a commercial anonymization network.
Amazon states that because the vulnerability was still under embargo at that time, targeting a honeypot from an anonymized IP address suggests the activity was conducted by a threat actor. Amazon also states it remains unclear how the actor acquired exploit information prior to disclosure. The company notes that it is unclear whether any of the observed attempts would have succeeded on real-world systems.
MadPot is Amazon's honeypot system. Amazon says it analyzes over 200 billion events per minute and integrates threat intelligence from the MadPot honeypot network to identify and block known exploitation attempts in real time.
PHP2Shell exploitation timeline
The PHP embargo window was scheduled to lift on 2026-10-21 at 1400 UTC. Exploitation activity clustered on both sides of that boundary.
| Time (UTC) | Event |
|---|---|
| 2026-10-17 | First PHP2Shell exploitation attempt against MadPot, from 103.216.220.92 |
| 2026-10-21 ~0200 | Earliest proof-of-concept exploits for the vulnerability identified, before the embargo lift |
| 2026-10-21 0200-0800 | Additional PHP2Shell exploitation attempts against MadPot from additional anonymized infrastructure, with varying payloads |
| 2026-10-21 1400 | Embargo lifted and patch released |
| After 2026-10-21 1400 | Further proof-of-concept exploits appeared within hours and were used against Amazon sensors almost immediately |
Amazon describes the payloads and the choices of anonymization infrastructure as varied, which suggests these were multiple actors rather than one. The company states that PHP2Shell is now being broadly exploited in the wild.
An embargo protects defenders only until someone else finds the same bug
Amazon's first stated lesson is that coordinated disclosure remains the right model, but that defenders should not assume the public disclosure date is the earliest date of exploitation. With PHP2Shell, compromise may predate the advisory. The Oct. 17 honeypot hit is the concrete evidence Amazon offers for that claim.
The patch-to-exploit window is shrinking for structural reasons
Amazon's second lesson is that the time from patch to working exploit is contracting. In the past, Amazon says, most exploitation it observed came after a public proof-of-concept release: a small number of capable actors built exploits and everyone else waited for them. Amazon says that dependency is weakening because AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit. As a result, more actors can act within hours or even minutes once technical details of a vulnerability are disclosed.
What security leaders should change
Amazon lists three working assumptions that it says this event invalidates:
- For critical vulnerabilities in internet-facing systems, measure patch and mitigation timelines in hours. A 7-day or 30-day SLA assumes a delay that no longer exists.
- Start investigations from the earliest known exploitation, not from the disclosure date. For PHP2Shell, Amazon says to investigate from at least Oct. 17, 2026.
- Invest in detections that do not rely on a signature for a specific CVE, because the first exploitation will often come before those signatures exist.
Recommended remediation for PHP2Shell
Amazon lists five actions:
- Upgrade immediately to the fixed PHP versions. Amazon states that upgrading is the only complete remediation for both CVE-2026-109618 and CVE-2026-109619, and that there are no configuration-only workarounds that fully address both issues.
- Consider blocking multi-part file uploads in PHP deployments that cannot be patched immediately, after determining how that would affect the application.
- Look for POST requests containing the PHP_SESSION_UPLOAD_PROGRESS string in form uploads.
- Review web server logs for suspicious activity.
- Check for unexpected process execution or file modification on web application servers.
AWS also published a companion post on using AWS WAF to apply mitigations for the PHP2Shell RCE vulnerabilities while patching.
IP addresses observed by Amazon
Amazon published six IP addresses associated with the activity. It explicitly states that these addresses include shared anonymization infrastructure and are not exclusive to this threat activity, and that organizations should investigate observations involving these addresses rather than block them outright.
| IP address | Observed date |
|---|---|
| 103.216.220.92 | 10/17/2026 |
| 31.223.184.166 | 10/21/2026 |
| 37.19.200.5 | 10/21/2026 |
| 134.209.159.64 | 10/21/2026 |
| 103.114.163.188 | 10/21/2026 |
| 95.217.98.37 | 10/21/2026 |
What the Hacker News discussion adds
The Hacker News thread on the report (197 points, 55 comments) mostly turned on two questions: whether the exploitation Amazon describes was actually successful, and why Amazon's own Linux patching lagged behind the disclosure it was publicizing.
Was any observed activity an actual compromise?
Commenters asked whether Amazon distinguishes between exploitation attempts and successful infiltration. One commenter described only seeing probes rather than working exploits:
I've seen probing for it in server logs but not actual exploiting of it. I think the botnets added it to their vulnerability scanners but I have yet to see any examples of an actual working exploit. There are hundreds of vibe coded attempts on github but none of them work to the best of my knowledge.
Another commenter asked whether the exploit is easy to use at all, noting that a separate article argued the exploit is not easy and needed local file inclusion (LFI). Amazon itself states it is unclear whether any of the attempts would have succeeded in real-world systems, so the source material does not resolve this question.
Amazon's own patch timeline drew criticism
Several commenters argued the blog post undercuts its own message because Amazon Linux packages lagged the patch release. One commenter pointed to a GitHub issue on the amazonlinux/amazon-linux-2023 repository:
So Amazon knew about this exploit and that it was actively being used several days before the release of any patches. Despite this they still took 18 hours AFTER the release of the patches to provide updated version of their Amazon Linux packages?
Another commenter stated that Amazon's Amazon Linux patch was due on Oct. 22, and called the post embarrassing on that basis. These are commenter claims about Amazon Linux release timing; the AWS blog post itself does not discuss Amazon Linux package availability.
Overlap with other vendors' telemetry
One commenter cited a tweet by Matthew Prince stating that Cloudflare saw thousands of attempts before the announcement, tens of thousands after it, and millions by the time of the tweet. The same commenter flagged a timeline ambiguity: if the announcement refers to 14:00 UTC, that is several hours after Chainguard published its images, and a precise timeline would help establish whether actors derived exploits from those builds.
Criticism of the PHP project's disclosure handling
Part of the thread questioned how exploitation could begin so close to the private notification of researchers and PHP insiders. One commenter wrote:
It's pretty telling that the attacks started after the vulnerability was found by researchers and PHP insiders notified. Who really believes that a malicious entity found the exact same exploit chain at the same time fully independently?
Another commenter was harsher about the PHP team's public communication, describing the response as deflecting blame toward Chainguard and toward funding concerns. A third commenter generalized the criticism into a broader complaint that vendors were competing over who detected the vulnerability first rather than shipping fixes for customers.
What remains unresolved
The source material leaves several questions open. Amazon does not say how the pre-disclosure actor obtained exploit details, whether any attempt succeeded, or which specific actors were behind the varied payloads. The comment thread raises the possibility that the Oct. 17 activity was pre-disclosure weaponization, but neither Amazon nor the commenters provide evidence establishing that chain. Amazon's operational guidance, however, does not depend on those answers: patch internet-facing PHP deployments in hours, begin forensic timelines at the earliest known exploitation date, and rely on behavioral detections rather than CVE-specific signatures.