PHP2Shell: Patch NOW

news Oct 21, 2026

If you run anything on PHP (and statistically, you do), stop reading this and go patch. Then come back.

PHP2Shell is the name for two critical PHP bugs, CVE-2026-109618 and CVE-2026-109619, that let attackers execute code remotely on web servers without logging in. These bugs live in the PHP engine itself, so your application code being clean doesn’t save you. Magento, Shopware and WooCommerce stores are all exposed even with spotless code of their own.

Both bugs come from how PHP cleans up after a request dies badly. PHP handles certain fatal conditions, like blowing past its configured memory_limit, through an internal mechanism called a bailout. That cleanup is where things break. CVE-2026-109618 (RCE via OOM corruption) happens when out-of-memory handling interrupts PHP while internal request data is only partially initialized, and the cleanup routine then treats that garbage data as valid. CVE-2026-109619 (RCE via stale global state) happens when request-owned internal state survives after its backing memory has been freed. That hands an attacker an unauthenticated heap use-after-free, memory disclosure, and code execution with the web worker’s privileges.

Both carry a CVSS v4.0 score of 9.2. watchTowr rated it a full 10.0, which I’d say is fair for unauthenticated RCE on the language that runs a huge chunk of the web. Every PHP installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, going all the way back to PHP 5.4. mod_php is the worst spot. The PHP team called out a demonstrated exploit there where an unauthenticated request triggers the attack before any application code runs, so your WAF rules tuned for app-layer attacks may not help much.

This one also didn’t go the way coordinated disclosure is supposed to go. Calif reported the first bug to PHP on August 11, and Wiz followed on August 24. Details leaked on October 20, and Cloudflare saw early attacks the morning of October 21, hours before PHP pushed fixes that afternoon. The original disclosure date was October 22. The AI angle is worth noting too. Calif, Wiz, and OpenAI researchers found these together, and Wiz said the flaws had been sitting there for decades until frontier AI models made it practical to chain them into a working exploit. I wrote about AI in our field a few weeks ago, and this is the other side of that coin. Defenders aren’t the only ones getting faster.

The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If you’re on anything older than 8.2, there’s no fix coming for your branch, so consider this your sign to finally schedule the upgrade you’ve been putting off. If you can’t patch right now, the PHP team gave temporary mitigations:

For CVE-2026-109618, set memory_limit=-1, ideally somewhere applications can’t override it, like php_admin_value in the FPM pool or Apache config.
For CVE-2026-109619, set session.upload_progress.enabled=0 and restart every worker.

Treat these as a stopgap. Disabling upload progress only blocks the confirmed session path for CVE-2026-109619, and unlimited memory opens you up to resource exhaustion, so keep an eye on your boxes. Since attacks started before the patch dropped, assume anything internet-facing has already been probed. Look for unexpected worker crashes, new files in web roots, and outbound connections from your web user. The writeups and an exploit tool are already public, so the bar for exploitation is now copy and paste.

Patch today, mitigate if you can’t, and go look for signs someone beat you to it. I’ll update this post as more details on in-the-wild exploitation come out.