PHP2Shell Attacks Began Before Disclosure: Patch PHP 8.2–8.5 and Hunt From October 17

What Amazon actually saw​

The evidence comes from MadPot, Amazon's honeypot network. It is not a count of victims.

• October 17: Amazon recorded an attempt that targeted its MadPot honeypot network. The source address was tied to a commercial anonymization network. Amazon says it is unclear how the actor learned of the flaws while they were under embargo.
• October 21, from about 02:00 to 08:00 UTC: Amazon saw more attempts from other anonymized infrastructure. The payloads and anonymization choices varied, which Amazon reads as a sign of multiple actors. This was before the 14:00 UTC embargo lift.
• After the 14:00 UTC release: more proof-of-concept exploits appeared within hours. Amazon says they were used against its sensors almost immediately. AWS CISO CJ Moses calls PHP2Shell "now being broadly exploited in the wild."

Amazon also says technical analysis is ongoing and that it is unclear whether any of these attempts would have worked on real systems. So the defensible claim is that pre-disclosure targeting was observed. It is not that production servers were compromised before the patches existed.

BleepingComputer reports that the PHP team moved the release earlier after some details leaked, including the CVE IDs and mitigation advice given to some critical infrastructure providers. watchTowr's account agrees that details of the two flaws leaked online on October 20, before coordinated disclosure and before patches were released. BleepingComputer adds that Cloudflare, watchTowr, Previdian, Hadrian and Patchstack saw unsuccessful attempts before disclosure.

Other vendors corroborate the exploitation​

Amazon is not alone. Tenable's FAQ notes that Cloudflare CTO Dane Knecht said the company was "seeing early attacks emerging." watchTowr reports exploitation in the wild as of October 21 through its Attacker Eye honeypot network. Datadog's security team says it has multiple reports of active exploitation and is aware of broad untargeted scanning.

SOCRadar adds a caveat. As of October 21, PHP had not reported in-the-wild exploitation, and CISA had not added either CVE to its catalog. Most of the "exploited" claims come from security vendors who have not published technical details. Treat the picture as consistent but still developing.

The two vulnerabilities​

Both carry a CVSS v4 score of 9.2 and describe unauthenticated remote code execution.

CVE-2026-109618 (out-of-memory corruption).

• PHP uses longjmp() to bail out of a request on an out-of-memory error. In some contexts the request memory is reachable before it is fully initialized.
• An allocation failure at that moment leaves invalid state, and request shutdown can then read it.
• The advisory lists several ways a multipart request can exhaust memory while staying inside apparent limits. These include unlimited part headers, empty file controls that don't count toward max_file_uploads, and nested field names.
• Apache mod_php is the clearest case. The advisory says it runs shutdown even when startup failed, so the flaw can trigger before any application code runs. PHP confirmed full RCE against mod_php with default limits.
• PHP-FPM is judged susceptible by source analysis, but no complete FPM exploit has been shown for this CVE. FrankenPHP is likely susceptible. LSAPI exploits are considered likely but unvalidated.

CVE-2026-109619 (stale global state).

• A PHP worker keeps global state that points at memory owned by an earlier request. That memory is freed, and a later request on the same worker uses the stale pointer before normal initialization.
• Exploitation needs a "producer" and a "consumer" operation.
• The advisory says the strongest demonstrated case is a PHP 8.5 fatal-error backtrace. It also describes a session upload progress path that was validated against both mod_php and FPM.
• Session upload progress is enabled by default, and no session_start() call is required.

Datadog notes that its reproduction of the first bug used an unauthenticated POST that never reaches the target application's code. Application-level hardening alone therefore won't save you.

Affected and fixed versions​

The advisories list these fixed releases:

Anything older within those branches is affected. End-of-life branches such as 8.1, 8.0 and 7.x get no official upstream fix. Reports differ on how exposed they are. watchTowr says the vulnerabilities affect PHP 5, 7, and 8 in entirety. SOCRadar mentions source backports for 8.1, 8.0 and 7.4. If you run an EOL branch, check whether your Linux distribution or a commercial extended-support vendor has backported the fix. Don't assume a routine update is coming.

Vendors are also shipping packages. AlmaLinux, for example, has published patched PHP packages. It notes that AlmaLinux 8 only loads mod_php if Apache has been switched to the prefork MPM, and that is not the default. Your distribution's exposure may differ from upstream defaults.

What admins should do​

1. Upgrade to the fixed release. Both Amazon and PHP's advisories say this is the only complete remedy, and no configuration-only workaround fully covers both CVEs. Check the PHP runtime each web app uses, not just the one on your workstation. Restart workers and confirm they run the patched build.
2. If you can't patch yet, reduce exposure.
   • Amazon suggests considering a block on multipart file uploads, after checking the impact on your applications.
   • For CVE-2026-109619, the advisory says to set session.upload_progress.enabled=0 and restart every worker. This stops the demonstrated session path but not every lifecycle path. For PHP 8.5, set fatal_error_backtraces=0 and restart workers.
   • For CVE-2026-109618, the advisory names memory_limit=-1 as the primary configuration mitigation. It admits this is incomplete. It also advises keeping post_max_size conservative, enforcing request size at the frontend, and bounding input nesting, parts, headers and uploads.
   • The advisory warns against using RLIMIT_AS or RLIMIT_DATA as a memory limit, because that can trigger the vulnerable path.
   • These measures do not replace updating.
3. Hunt backward to October 17. Amazon says to start investigations from the earliest known exploitation date, not the disclosure date. Look for POST requests containing the PHP_SESSION_UPLOAD_PROGRESS string in form uploads. Review web server logs. Check for unexpected process execution or file changes on web application servers.
4. Use the IOCs carefully. Amazon lists six addresses: 103.216.220.92 (seen October 17), plus 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37 (seen October 21). Amazon says they include shared anonymization infrastructure, so investigate matches rather than blocking on them alone.

Why it matters beyond PHP​

PHP is a web development language that, per BleepingComputer, powers up to 80% of websites. That includes WordPress, Drupal and Joomla. VirusTotal tracks more than 5.1 million exposed PHP hosts, roughly 3.8 million of them with at least one open port. Windows shops are affected too, since IIS with FastCGI hosts PHP in many environments, and so do Linux containers on Azure. The fix applies wherever PHP serves web requests.

Amazon's broader argument is more provocative. It says an embargo protects defenders only until someone else finds the same bug. It also says AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit. Its advice is to measure patch timelines for critical internet-facing systems in hours, and to use detections that don't depend on a CVE-specific signature.

There are fair caveats. Amazon sells security services and has an interest in this framing. Its telemetry comes from honeypots, and the AI-acceleration point is its own assessment rather than something shown by this incident. The practical advice holds up either way. A 9.2-rated, unauthenticated RCE in the web runtime itself deserves a same-day patch and a log review that reaches back past the disclosure date.