PHP2Shell: PHP Rushes Out Emergency Fix for Two Critical RCE Flaws After a Leak

What PHP fixed

php.net says the new releases "fix two critical vulnerabilities that can allow unauthenticated remote code execution" and that "all PHP users are strongly encouraged to update immediately." Both CVEs are rated CVSS v4.0 9.2. A score of 10.0 circulated while the bugs were leaking; the PHP Foundation says that figure was wrong.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), "RCE via OOM corruption": out-of-memory handling can interrupt PHP while internal request data is only partially initialized, and request cleanup may then treat that invalid data as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), "RCE via stale global state": request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may use that stale state before normal initialization resets it.

Sansec describes both as use-after-free bugs. A fatal error, typically running out of memory, interrupts native code before cleanup, and later requests reuse the freed memory as if it were live data. Sansec adds that CVE-2026-109618 can also leak memory in a way "similar to Heartbleed": the upload-progress handler can return freed worker memory inside PHPSESSID cookies, potentially exposing passwords, session tokens, API keys and TLS private keys. Every known attack vector uses multipart/form-data requests, and default configurations are vulnerable.

Wiz Research, which chained the bugs into a single exploit script it calls php2shell, counts four exploitable bugs under the two CVEs: a use-after-free in the upload-progress unserializer, remote process-memory disclosure, a use-after-free in fatal-error backtraces, and an OPcache type confusion.

Who is affected

According to php.net, the risk covers "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." The project rates mod_php highest, with "a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

Because the flaws sit in the engine, the application on top offers little protection. Wiz demonstrated unauthenticated code execution against the official wordpress:latest, drupal:latest and joomla:latest container images. Sansec lists these applications as confirmed affected:

• Magento 2.4.9
• WordPress 7.1.2
• Drupal 11.4.3
• Joomla 6.1.4
• MediaWiki 1.46.2
• Roundcube 1.7.4
• phpMyAdmin 5.2.3
• Nextcloud 35.0.1
• Laravel 13.11 and Symfony 8.1
• WHMCS

Sansec and Wiz both say every PHP version released in the last decade is affected by at least one of the bugs. Wiz's headline puts the reach at "70% of the Internet".

Which version to install

• PHP 8.5: update to 8.5.12
• PHP 8.4: update to 8.4.27
• PHP 8.3: update to 8.3.36
• PHP 8.2: update to 8.2.35
• PHP 8.1 and older: no official release. Get a backported package from your Linux distribution or LTS vendor, or upgrade to a supported branch.

Given the severity, the PHP security team also published minimal source backports for PHP 7.4, 8.0 and 8.1 in the php-src repository on GitHub (branches PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 and PHP-8.1-CVE-2026-109618-109619) for anyone who builds PHP from source.

Linux distributions and LTS vendors received the patches in advance. The exception is the volunteer-run rpms.remirepo.net repository: PHP told its users to switch to distribution packages or build from source, because "The repo will not have updates today." After updating, restart PHP-FPM pools or Apache so no worker keeps running the old code.

If you cannot patch today

php.net published interim mitigations, with a clear warning that they reduce exposure but "do not make an installation safe".

For CVE-2026-109618

• Set memory_limit=-1, ideally through php_admin_value so applications cannot override it.
• Set a low post_max_size: 8M if the site takes no uploads, 32M if it does.
• Keep upload_max_filesize below post_max_size.
• Cap memory with a container or cgroup limit, not with RLIMIT_AS or RLIMIT_DATA.

For CVE-2026-109619

• Set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server config. ini_set() and .user.ini do not work for this setting.
• Restart every PHP worker after the change.
• On PHP 8.5, also set fatal_error_backtraces=0.

CISA's alert, "Critical Vulnerabilities in PHP Require Immediate Patching", asks organizations to inventory every PHP system, patch internet-facing ones first, take PHP systems offline if they cannot be patched (especially PHP 8.1 or earlier), put a web application firewall in front for interim protection, and monitor PHP worker processes for suspicious activity.

Wiz suggests watching for unusual multipart requests, memory-limit errors, HTTP 500 responses, malformed PHPSESSID cookies and PHP worker churn.

A leak, a broken embargo and early attacks

PHP had planned to ship the fix on 22 October at 14:00 UTC. Around 15:00 UTC on Tuesday 20 October, the PHP Foundation says, the two CVE IDs began circulating online. PHP posted a pre-announcement at 19:30 UTC, reserving the right to release early if details went public or exploitation appeared, and sent mitigation advice to critical-infrastructure operators at 23:00 UTC.

The next morning the embargo fell apart. In the Foundation's words: "On October 21st at 07:41 UTC, more than six hours before the coordinated release, Chainguard unilaterally broke the embargo and published built images containing the fix." PHP moved the release forward a full day, to 21 October at 14:00 UTC.

Cloudflare says customers on its free and paid WAF were "protected by default against php2shell" from 03:02 UTC on 21 October, roughly nine hours before public disclosure. It saw attackers mutating payloads to slip past the rules and still recommends patching PHP. Alongside the rules it launched "full transaction detection", which combines request and response signals from the same HTTP transaction.

Reports on exploitation differ. Sansec's timeline records "Cloudflare reports early attacks" at 07:43 UTC on 21 October, before the release, and says watchTowr confirmed code execution on 20 October after the leak. CISA, in its 21 October alert, said it "has not observed exploitation of these vulnerabilities as of the time of publication."

AI, and a fix that took months

Wiz says it used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout the research, and that "frontier models substantially reduced that barrier, turning a longstanding flaw into an exploit." By its account, one researcher did in a week what would previously have taken "a world-class team months of work".

AI did not find the bugs on its own, though. The PHP Foundation says the out-of-memory weakness was known in some form since 2024, when a Foundation developer saw signs of it while fixing issues from an external audit by Quarkslab, funded by the Sovereign Tech Agency through OSTIF. Security firm Calif began auditing PHP on 30 July 2026 through the Patch the Planet programme, and on 11 August Ryan A of Calif reported unconditional remote code execution. OpenAI independently reported the same root cause that day. Wiz reported more attack vectors on 24 August, and OpenAI reported more on 18 September. Trail of Bits is also auditing PHP.

The Foundation also uses AI on defense: "Earlier this year, we worked with Alpha-Omega to scan PHP with Anthropic's Claude Mythos. But since the Mythos scan, we have added other tools, including OpenAI's Daybreak Red for validating reports and exploits, alongside sanitizer builds and reproduction environments that match our CI on every platform PHP supports."

It is blunt about the ten weeks between the August report and the October release: "the delay was a structural failure, caused by both the security team's decision process and its lack of resources." Each candidate fix carried trade-offs - backward-compatibility breaks, new denial-of-service potential, or changes needed across many third-party extensions - and with only a small team of core engine experts, the Foundation says, the work stalled and restarted repeatedly over months.

The Foundation set up an Ecosystem Security Team in May 2026. Alexandre Daubois joined in July to handle triage, reports and fixes, and Daniel Scherzer joined in September to work on hardening.

Sources

• PHP security release announcement, 21 October 2026: https://www.php.net/archive/2026.php#2026-10-21-5
• PHP pre-announcement, 20 October 2026: https://www.php.net/archive/2026.php#2026-10-20-1
• The PHP Foundation: https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
• Wiz Research: https://www.wiz.io/blog/php2shell-php-rce
• Sansec: https://sansec.io/research/php2shell
• Cloudflare: https://blog.cloudflare.com/php-vulnerabilities-waf-protection
• CISA alert: https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
• GitHub advisories: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w and https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

Key takeaways

• Update now: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Both CVEs are rated CVSS v4.0 9.2, not the 10.0 that circulated during the leak.
• Every PHP install serving web requests is affected, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php carries the highest risk.
• PHP 8.1 and older get no official release: use distribution or LTS packages, the source backports, or upgrade.
• Config mitigations and WAF rules only buy time. php.net says they do not make an installation safe.
• The release moved up a day after the CVE IDs leaked and Chainguard broke the embargo. Cloudflare saw early attacks; CISA had not observed exploitation when it published.