Amazon finds PHP2Shell exploits in honeypots four days before CVE disclosure

Amazon's threat intelligence team says it detected attempts to exploit the PHP2Shell vulnerabilities in its honeypot network on October 17, 2026 — four days before the flaws, tracked as CVE-2026-109618 and CVE-2026-109619, were publicly disclosed. According to the AWS Security Blog, the vulnerabilities are now broadly exploited in the wild.

Exploitation predates the advisory

The first exploitation attempt surfaced in telemetry from MadPot, Amazon's honeypot network, on October 17. According to the blog post, the attempt originated from an IP address associated with a commercial anonymization service. Because the vulnerability was still under embargo at the time, Amazon concludes that a threat actor held exploit information before disclosure, though the company says it remains unclear how that information was obtained.

The embargo on the PHP flaws was set to lift at 14:00 UTC on October 21. On the day of the release, Amazon says it identified multiple proof-of-concept exploits, with the earliest appearing around 02:00 UTC — roughly twelve hours before the embargo ended. Between 02:00 and 08:00 UTC, further exploitation attempts hit MadPot sensors from additional anonymized infrastructure. The payloads and the anonymization services varied across attempts, which Amazon reads as evidence of multiple distinct actors rather than a single group.

Exploits appeared within hours of the patch

Once the embargo lifted and patched PHP versions shipped, new proof-of-concept exploits appeared within hours and were used against Amazon's sensors almost immediately, the company reports. Technical analysis is ongoing, and Amazon notes it is unclear whether any of the observed attempts would have succeeded against real-world systems.

Amazon's two takeaways

Amazon draws two broader lessons from the event. First, an embargo protects defenders only until someone else independently finds the same bug: coordinated disclosure remains the right model in the company's view, but defenders should not assume the public disclosure date is the earliest possible exploitation date. For PHP2Shell, compromises may predate the advisory.

Second, the time from patch release to working exploit is shrinking for structural reasons. In the past, Amazon says, most exploitation followed the release of a public proof of concept, with a small number of capable actors building exploits and everyone else waiting for them. That dependency is weakening. AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit, allowing more actors to act within hours or even minutes of disclosure.

For security teams, Amazon says this changes several working assumptions: patch and mitigation timelines for critical internet-facing vulnerabilities should be measured in hours rather than a 7- or 30-day SLA; investigations should start from the earliest known exploitation — October 17 in this case — rather than the disclosure date; and detection investment should not depend on signatures for a specific CVE, since first exploitation often arrives before those signatures exist. Amazon adds that its internal threat intelligence system, which analyzes over 200 billion events per minute, automatically detected and restricted malicious scanning attempts targeting the vulnerability.

Recommended actions

Amazon says upgrading to the fixed PHP versions is the only complete remediation for both CVEs; there are no configuration-only workarounds that fully address the two issues. For deployments that cannot be patched immediately, the blog suggests considering a block on multi-part file uploads, while first checking what that would break in the application.

On the detection side, Amazon recommends looking for POST requests containing the PHP_SESSION_UPLOAD_PROGRESS string in form uploads, reviewing web server logs for suspicious activity, and checking web application servers for unexpected process execution or file modifications. The company has also published a separate post on using AWS WAF to reduce exposure while patching.

Amazon's blog lists six IP addresses observed in the activity, one on October 17 and five on October 21, but cautions that they belong to shared anonymization infrastructure and are not exclusive to this campaign — organizations should investigate any observations involving them rather than simply blocking.

Why it matters

This is a concrete data point for a trend defenders have been warned about: attackers no longer wait for public proof-of-concept code, and private knowledge of a vulnerability can surface — or be independently rediscovered — well before disclosure. For anyone running internet-facing PHP, the practical consequences are immediate: patch in hours, not days, and treat October 17, not October 21, as the earliest possible compromise date when reviewing logs. The AI angle is the more unsettling part — if turning a patch diff into a working exploit keeps getting cheaper, the scramble after every major disclosure will only intensify, and signature-based defenses will keep arriving too late.