Amazon Saw PHP2Shell Exploit Attempts Four Days Before PHP Shipped the Fix

An unauthenticated attacker can run code on a PHP web server through either of two flaws, CVE-2026-109618 and CVE-2026-109619, and Amazon's honeypots logged an exploitation attempt on Oct. 17, four days before PHP shipped the fix. Both are rated 9.2 on the CVSS v4.0 severity scale, and the fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

PHP published the patches at 14:00 UTC on Oct. 21. Amazon Threat Intelligence wrote in an AWS Security Blog post that its MadPot honeypot network recorded the first known attempt on Oct. 17, from an address tied to a commercial anonymization network. The post gives no attempt counts and says it is unclear whether any attempt would have worked.

What an attacker needs for CVE-2026-109618 and CVE-2026-109619

The two bugs are described in a Qualys write-up of PHP's advisories, and neither needs credentials or user interaction. CVE-2026-109618 is an out-of-memory bailout that leaves request data half-initialized, which PHP then treats as valid during shutdown. CVE-2026-109619 is a use-after-free in which request-owned global state outlives its memory and a second request on the same worker reads it.

The 9.2 score carries an attack complexity of high, because success depends on allocator layout, the build and worker scheduling. It does not mean the bugs are hard to reach. Under Apache mod_php, one request is one attempt, and PHP's advisory rates mod_php as the highest risk because the attack can land before application code runs. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed are also exposed, and Qualys says PHP validated a session-upload path against FPM under suitable application conditions.

The timeline of Oct. 17 to Oct. 21, in UTC

Date and time	Event	Source
Oct. 17	First exploitation attempt in Amazon's MadPot data	AWS
Oct. 20, evening	PHP posts advance notice and moves release up from Oct. 22	The Hacker News
Oct. 21, 03:02	Cloudflare turns on stopgap firewall rules by default	The Hacker News
Oct. 21, 14:00	PHP publishes 8.5.12, 8.4.27, 8.3.36, 8.2.35	AWS, The Hacker News
Oct. 21, 14:19	watchTowr reports active exploitation attempts on both CVEs	The Hacker News

The Hacker News reported that Wiz Research, Calif and OpenAI's Codex Security team found the flaws, and that Calif mistakenly posted a video of a working proof of concept around 20:00 UTC on Oct. 20. That is the only source for the video. Amazon's date is three days earlier, so the earliest attempt did not come from that video.

PHP core developer Gina Peter Banyard wrote before the release: "The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much." The same report says the PHP Foundation found signs of the out-of-memory flaw in a 2024 external audit, with no working attack at the time. For another recent bug chain that sat unpatched in the wild, see Plex2Shell.

71 percent of installations are on unpatched branches

The patch list stops at PHP 8.2. Qualys counted about 167 million PHP package installations in its customer telemetry, 156 million with a known version, and found 110 million on end-of-life branches (5.4 to 8.1) against 44 million on supported ones (8.2 to 8.5). It saw only 199,000 patched in the first 12 hours. Those are Qualys's own figures and cover its customers only.

1. End-of-life branches (5.4 to 8.1)110 million
2. Supported branches (8.2 to 8.5)44 million

Source: Qualys blog, PHP2Shell, accessed 2026-10-27

PHP published limited source backports for 7.4, 8.0 and 8.1. PHP 8.2 itself reaches end of life on Dec. 31, 2026, according to The Hacker News. For a contrast in response speed, see the earlier report on eMudhra's weak CA keys, which Chrome blocked in 100 minutes.

Workarounds, and why PHP says they are not enough

PHP's interim guidance for CVE-2026-109618 is to set memory_limit=-1, cap post_max_size at 8M without uploads or 32M with them, and bound multipart requests at the proxy. For CVE-2026-109619 it is session.upload_progress.enabled=0 in php.ini or the FPM pool, with workers restarted, plus fatal_error_backtraces=0 on PHP 8.5. Setting it with ini_set() or .user.ini does not count. PHP says these reduce exposure and do not make an unpatched server safe.

Amazon suggests searching logs for POST requests containing PHP_SESSION_UPLOAD_PROGRESS and warns that its six listed IP addresses are shared anonymization infrastructure, so they are leads rather than block-list entries. Qualys warns that public proof-of-concept scripts on GitHub are not safe validation tools. Neither flaw was in CISA's Known Exploited Vulnerabilities catalog when The Hacker News published, and no source has confirmed a successful break-in.

Upgrade to the fixed version for your branch, restart every worker, and check the binary that serves web requests, because php -v may report a different one. Distribution packages can carry older version numbers with backported fixes, so read the vendor advisory.