Amazon Threat Intelligence found a PHP2Shell exploitation attempt in its MadPot honeypot telemetry dated Oct. 17, 2026, four days before the PHP project published fixes for CVE-2026-109618 and CVE-2026-109619 on Oct. 21 at 14:00 UTC.
What Amazon’s honeypots recorded
In a post published Oct. 21, Amazon says the Oct. 17 attempt came from an IP address associated with a commercial anonymization network. The flaws were under embargo at the time. Amazon wrote that targeting a honeypot from an anonymized address suggests a threat actor was behind the activity, and that it remains unclear how the actor acquired exploit information before disclosure.
The Oct. 21 record is denser. Amazon identified multiple proof-of-concept exploits on the day of the release, the earliest around 02:00 UTC, twelve hours before the embargo lifted. From 02:00 to 08:00 UTC it saw further attempts against MadPot from additional anonymized infrastructure. The payloads and the anonymization choices varied, which Amazon reads as multiple actors. Its technical analysis is ongoing, and it says it is unclear whether any of these attempts would have succeeded against real systems.
After the patch shipped at 14:00 UTC, Amazon saw more proof-of-concept exploits within hours and watched them used against its sensors almost immediately. Its post states that PHP2Shell is now being broadly exploited in the wild.
The flaws and the fixed versions
A companion Amazon post on AWS WAF mitigations for PHP2Shell describes the two flaws. Both are critical remote code execution issues in the PHP core runtime, rated 9.2 under CVSS v4.0, and both let an unauthenticated attacker run code on a vulnerable server. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Both flaws sit in how PHP processes multipart/form-data requests, the format used for file uploads, before application code runs. CVE-2026-109618 corrupts memory when PHP runs out of memory during a request. CVE-2026-109619 lets one request leave stale data behind that a later request on the same worker process reuses. This site reported the Oct. 21 fix window in advance: PHP Gives Advance Notice of Two Critical Flaws, Fix Due Oct. 21 at 14:00 UTC.
Amazon’s guidance is consistent across both posts. Upgrading is the only complete remediation, and no configuration-only workaround fully addresses both issues. For deployments that cannot patch immediately, Amazon suggests considering a block on multipart uploads after checking the effect on the application, and its WAF post covers rules that reduce exposure during the patch window.
Why the disclosure date is the wrong starting point
The most useful part of Amazon’s post is a pair of lessons it draws for defenders. The first concerns embargoes. “An embargo protects defenders only until someone else finds the same bug,” wrote CJ Moses, CISO of Amazon Integrated Security, in the post. Amazon adds that coordinated disclosure remains the right model, but defenders should not assume the public disclosure date is the earliest date of exploitation, and that with PHP2Shell, compromise may predate the advisory.
The second lesson concerns speed. Amazon says most exploitation it used to observe followed a public proof of concept, built by a small number of capable actors while everyone else waited. It argues that dependency is weakening because AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit, so more actors can act within hours or even minutes of disclosure. That is Amazon’s assessment from its own telemetry, and the post offers no measurement of how many actors are using such tools.
The PHP2Shell timeline fits the shape Amazon describes, with the caveat that its Oct. 17 attempt is a single honeypot observation. A similar gap appeared in an earlier case we covered, when attackers probed mail servers between a Zimbra fix and its disclosure.
What it means for the security leader
Amazon recommends measuring patch and mitigation timelines for critical, internet-facing vulnerabilities in hours, and says a 7-day or 30-day SLA assumes a delay that no longer exists. In our reading, the less obvious change is the investigation start date. A team that finishes patching on Oct. 22 and keeps web server logs for fewer than five days has already lost the record of Oct. 17. Log retention for internet-facing PHP hosts belongs in the same conversation as the patch deadline.
The second consequence is inventory. Amazon’s own guidance starts with finding where PHP runs, because a fleet cannot be upgraded or even mitigated until someone can list it. Hosts managed by vendors, container images that bundle PHP and older internal applications are the usual gaps in that list. This site has argued before that the patch clock should start on release day, and PHP2Shell moves the clock one step earlier for the investigation.
What defenders should do now
Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a later release in the same line. Where an upgrade has to wait, deploy the mitigations from Amazon’s WAF post in count mode first, confirm they do not match legitimate traffic, and then switch them to block. Treat those rules as a stopgap, because Amazon states that patching is the only complete fix.
Review web server logs back to at least Oct. 17 on every PHP host exposed to the internet. Amazon’s post lists indicators and a log pattern to search for in POST requests, and it notes that the IP addresses it published belong to shared anonymization infrastructure, so teams should investigate any observation involving them and not simply block them. Check PHP application servers for unexpected process execution or file modification, which Amazon names as signs worth investigating.
Finally, extend log retention on those hosts if it is under a week, and record the Oct. 17 date in the incident notes so the next review starts from the earliest known activity.
Source: Amazon Threat Intelligence post on PHP2Shell exploitation in MadPot, Oct. 21, 2026
