Protect.Computer
NEWS

Amazon: PHP2Shell Exploitation Began Four Days Before Patches

· 2 min read · Got hacked Device safety
Amazon: PHP2Shell Exploitation Began Four Days Before Patches

Amazon Threat Intelligence says attackers began trying to exploit the PHP2Shell flaws on October 17, four days before PHP released its fixes on October 21. Its honeypot network, MadPot, recorded the first attempt from an address on a commercial anonymization network on October 17 and more attempts, with varying payloads that suggest multiple actors, after the fixes were released. Amazon says it is unclear whether any of them would have worked against real systems or how the earliest actor learned the details under embargo, but it now describes PHP2Shell as “broadly exploited in the wild.”

The PHP Foundation has said the coordinated disclosure was disrupted when details, including the CVE ids and mitigation advice given to some critical infrastructure providers, leaked online two days before release, and that Chainguard published images containing the fix more than six hours before the planned release. BleepingComputer reports that proofs of concept were also published before the patches, though the PHP security team said none were functional at that time. This follows our posts on the advance warning and the patch release.

How to check if you’re affected

Affected products are PHP installations older than 8.5.12, 8.4.27, 8.3.36 or 8.2.35 within their release branch; see our patch-release post for the full version and backport details. Check the version with php -v or your hosting panel, and do the same for PHP inside container images.

  • Amazon says upgrading is the only complete remediation for both CVE-2026-109618 and CVE-2026-109619, and that no configuration-only workaround fully covers both.
  • For deployments that cannot be patched immediately, Amazon suggests considering blocking multipart file uploads, after checking how that affects the application.
  • Because exploitation may predate the advisory, Amazon advises starting any investigation from at least October 17, not from the October 21 disclosure date.
  • Look in web server logs for POST requests containing the string PHP_SESSION_UPLOAD_PROGRESS in form uploads, and check web application servers for unexpected process execution or file modification.
  • Amazon lists six IP addresses seen in its attempts (103.216.220.92 on October 17; 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37 on October 21). It notes they include shared anonymization infrastructure and should be investigated where they appear in your logs rather than simply blocked.

Sources

Related reading