PHP releases emergency patches for PHP2Shell flaws as exploit attempts rise

The PHP project released emergency updates for CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell, in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 around 14:00 UTC on October 21, 2026. watchTowr reported active exploitation attempts against both flaws at 14:19 UTC on October 21, 2026. No source has reported a confirmed break-in of a specific server, and neither flaw was in CISA’s Known Exploited Vulnerabilities catalog as of 11:26 UTC on October 21.

The two flaws sit in the PHP runtime rather than in applications, so even a secure site on a vulnerable version is exposed. They let an unauthenticated attacker run code on a web server without an account, and the vulnerable code had existed in PHP for more than a decade. The flaws affect nearly every PHP version back to PHP 5.4.

Cloudflare counted thousands of exploit attempts before the public announcement, tens of thousands within 45 minutes, hundreds of thousands within two hours, and eventually millions. Attackers changed payloads to get around Cloudflare firewall rules switched on by default at 03:02 UTC before the patch.

Researchers at Wiz, Calif, and OpenAI found and reported the flaws, working with the PHP security team and Google’s Gemini team on the fix. AI models let one researcher convert the long-standing flaws into working exploits in about a week; the researchers say that work would otherwise take team months. OpenAI predicted that similar AI-discovered vulnerabilities would increase sharply in the coming months.

In early August, Wiz researcher Sagi Tzadik asked an AI agent to test a WordPress flaw against Drupal, and the agent instead found a PHP flaw. Calif, working with OpenAI, used AI to find a related PHP flaw unknown to Wiz’s team. OpenAI said the PHP bugs were among several significant vulnerabilities it has found and is working to fix.

PHP posted an advance notice on October 20, 2026, and moved the release to October 21 after a Hacker News post said the flaws were set for disclosure on October 22. Calif mistakenly posted a video of its working proof of concept around 20:00 UTC on October 20. Chainguard published built images containing the patch at 07:41 UTC on October 21, about six hours before the fix shipped.

BambooHR took its service offline across the United States, Canada, and Ireland, interrupted payroll, and had no restoration time. In the Netherlands, MijnOverheid, DigiD, the lower house of parliament’s site, the national cyber-security center, and several education systems went offline as a precaution. Government agency webpages and parts of Wikipedia were taken down as a precaution after the patch was released.

Updating the PHP runtime and restarting Apache, PHP-FPM, and long-running PHP workers is the only complete fix. Updating WordPress or Laravel does not update the PHP runtime beneath them; that comes from the server package, host, or container image. The PHP project no longer issues updates for PHP 8.1 and older branches, while PHP 8.2 reaches end of life on December 31, 2026. The PHP security team published source backports for PHP 7.4, 8.0, and 8.1.

For CVE-2026-109618, PHP advises setting memory_limit=-1, holding post_max_size low, and capping request size via the web server or proxy. PHP warns that RLIMIT_AS and RLIMIT_DATA can activate the same vulnerable path, so they cannot substitute for CVE-2026-109618. Turning off session upload progress blocks confirmed session paths but not other variants, and no configuration change fully mitigates CVE-2026-109619 short of updating.

After updating, review memory_limit and post_max_size because the fix adds a hard memory limit that ends the process and stops shutdown handlers. Researchers suggest watching for unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, oddly large PHPSESSID cookies, and unexplained PHP worker restarts. The highest risk is on servers using Apache’s mod_php, where one unauthenticated request can trigger the attack before application code runs.

PHP-FPM shuts the worker down when a request fails early in setup. Researchers showed no complete FPM exploit for one flaw and code execution on both mod_php and PHP-FPM for the other. An attacker can read memory from the PHP worker process, potentially holding passwords, authentication tokens, API keys, and certificates from other requests, without code execution.

The SANS Internet Storm Center handler assesses that building a universal, reliable, one-click exploit is difficult based on the published PoCs. Published PoCs require a memory limit of 8 MB, while real-world setups usually use 128 MB and a single-worker prefork Apache configuration. One published PoC sends 1001 small fields of 3000 bytes each plus a 12 MB field in a POST request to create allocation pressure.

The exploit leaks the Zend MM chunk base and libphp.so base address via zval_ptr_dtor to defeat ASLR, then changes pDestructor to zif_system, limiting commands to 14 bytes. Published PoCs read offsets from libphp.so on the target server, so they do not work universally without knowing the target’s build. The SANS handler says there is an unbelievable amount of AI-generated slop among the published PoCs. The SANS handler says setting session.upload_progress.enabled = 0 should help, though there is apparently a way to bypass even the currently available fix.

PHP’s 2024 external audit turned up early signs of the out-of-memory flaw behind CVE-2026-109618, though the audit work only theorized an attack and found no concrete path to code execution. The fix stalled for months as rival patches risked compatibility breaks, denial-of-service paths, and required changes to third-party extensions. The PHP Foundation called the delay a structural failure and has since changed security decision-making and added staff and tooling.

15 researchers from competing companies shared findings with no contracts and spoke almost daily over weeks, a process based on trust.