PHP Patches php2shell Flaws as Governments Say Update or Go Offline

The PHP project has released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can let an unauthenticated attacker run code on a web server. The worst case is Apache with mod_php. There, the PHP project says, an unauthenticated request can trigger a demonstrated exploit before any of the site's own code runs, and its advisory for the first flaw says that exploit was validated against default PHP input and memory limits and ordinary prefork setups. The pair is known as php2shell.

PHP runs 69.3% of the websites whose server-side language W3Techs can identify. CISA told organizations to patch immediately, and governments in the United States, Europe and Japan told operators to patch or take their sites offline. The PHP project's own line is blunter: "There are no complete mitigations, updating is the only safe choice." The flaws were reported by researchers at Calif, Wiz and OpenAI, and each of the three describes the part AI models played in its own terms.

Attack attempts are under way but no break-in is confirmed

Through October 21 the reports were of attempts, not break-ins. CISA, Huntress and the Dutch NCSC had seen no exploitation when they published, Huntress among its partners as of 10 a.m. Eastern (14:00 UTC) and the NCSC according to the broadcaster NOS. watchTowr's Jake Knott told The Register that the firm was seeing attempts carrying php2shell user agents, adding that "nobody has been successful to date." Cloudflare says it observed attack traffic aimed at its customers and watched attackers mutate their payloads to slip past its rules; according to Cloudflare and NOS, those attacks began before the patch shipped. The Hacker News reported that watchTowr saw attempts against both CVEs and that no source had reported a confirmed break-in of a specific server. On that record, attempted exploitation is documented and a successful compromise is not.

That gap may not last. CERT-EU says initial proofs of concept have begun to circulate, which in its words "raises the likelihood that attackers are already exploiting the vulnerabilities." The SANS Internet Storm Center raised its infocon to yellow, citing early proof-of-concept exploits that appeared before the patch, although it judged one public example, a multipart POST with a filename of roughly 5 MB, unreliable. Knott told The Register that watchTowr did not expect that run of failures to last long, and CloudLinux reports that the security firm Sansec expects mass exploitation to follow the release.

Governments told operators to patch or take their sites offline

Government cyber agencies in the United States and Europe told operators to patch at once, and several told them to take a site offline if they could not. The NSA, on its NSA Cyber account, advised organizations that could not update immediately to "take the system offline until it can be fully mitigated." CISA's alert adds older releases: organizations that cannot update immediately, or that still run PHP 8.1 or earlier, should take PHP-based systems offline until they are patched. CERT-EU suggests isolating internet-facing applications from public networks where patching is not feasible. France's ANSSI wrote that rapid exploitation of the two flaws "is to be feared" (translated from French), the UK's NCSC urged British organizations to take immediate action, and Italy's CSIRT told operators to check for compromise as well as update.

In Japan the request came from the head of government. Prime Minister Sanae Takaichi posted on X at 12:55 UTC (21:55 JST), before the patches were out, what she called, in X's translation from Japanese, "an urgent request for everyone to take action tonight." She asked operators to check whether their public websites use PHP and to be ready to apply the patch due at 11 p.m. JST (14:00 UTC), and wrote that if a quick patch was hard, temporarily suspending websites "can be considered an effective way to reduce risk." The post had passed 34 million views by Wednesday evening European time, according to X's counter. Japan's National Cybersecurity Office followed on X at 13:57 UTC, asking operators to apply the update as soon as possible and warning that websites could otherwise be compromised.

The Netherlands acted on that advice in public. The Dutch NCSC took its own website offline as a precaution, and Justice and Security Minister David van Weel wrote on X that the impact of the PHP flaws could be considerable, which was why the NCSC was advising organizations to take their sites offline for a while. NOS reported that MijnOverheid.nl, the DigiD login service, the House of Representatives' site, the NCSC and the data protection authority went offline, along with the RTL news site and app and the tech site Tweakers. The Register reported that Finnish government services were also taken down as a precaution and that the privacy group noyb temporarily withdrew its website.

Private operators made the same call. Wikimedia took down all of Cloud VPS and Toolforge and every Wikibase cloud instance while it applied the patches, warning that because those services host a large number of PHP applications they could stay offline longer; it later restored some developer and translation services and advised anyone running MediaWiki or other PHP deployments to update immediately. BambooHR took its service offline across the United States, Canada and Ireland and warned that payroll would be interrupted, according to The Hacker News.

One flaw breaks on memory exhaustion, the other on stale state

CVE-2026-109618 sits in how PHP gives up on a request that runs out of memory. PHP uses longjmp() to jump out of the current context, which can interrupt it while internal request data is only partly set up; the cleanup that runs at the end of the request then reads that half-built data as if it were valid. Getting a server there is easier than the default limits suggest. The advisory says a multipart request without a usable declared length can pass the initial post_max_size check and keep feeding decoded body data, and Calif says hundreds of nested empty-upload records can fill more than PHP's default 128 MiB heap while the whole HTTP body stays under the default 8 MiB post_max_size.

CVE-2026-109619 is a reuse problem. Internal state owned by one request can outlive the memory behind it, and a later request on the same worker may use that stale state before normal initialization resets it. The second advisory says the demonstrated cases plant the state in one HTTP request and consume it in another handled by the same worker. Session upload progress, which is on by default, is one confirmed path. On PHP 8.5, the path through fatal-error backtraces is the strongest demonstrated case and the basis of the confirmed mod_php exploit. Both flaws carry a CVSS v4 score of 9.2, rated critical, in the GitHub advisories and in CERT-EU's assessment.

mod_php is exposed by default, PHP-FPM through application code

The server setup decides how far an attacker gets without help from the site's code. For the out-of-memory flaw, Apache's mod_php runs request shutdown even when request startup has failed, so a body that exhausts memory during automatic parsing sends PHP into shutdown on invalid state, entirely before application code starts. PHP-FPM instead exits the child process when startup fails, and for this flaw the PHP project says no complete FPM exploit has been demonstrated, although its source analysis finds FPM susceptible. FrankenPHP, which like mod_php calls request shutdown unconditionally, is likely susceptible to attacks that need no application code, and the PHP project's list of installations at risk also includes php-cgi and LiteSpeed.

The stale-state flaw reaches FPM by another route. Its advisory says remote code execution through the session lifecycle was validated against both mod_php and FPM; on FPM, the validated path plants state while the application runs after a normal startup, hits a fatal error and then uses session upload progress to consume it, which works on a normal dynamic FPM pool but depends on a suitable operation in the application. Calif, for its part, calls the FPM exploit application-dependent, reached through decoding after startup such as session_start() or WordPress's maybe_unserialize(), and shows a demonstration against Nginx with PHP-FPM. Red Hat, assessing CVE-2026-109618, says FPM can be reached through application-stage paths but calls remote code execution there difficult in practice, typically requiring non-default behavior. FPM servers are therefore probably harder to hit than mod_php ones, but nothing in the PHP project's own advisories supports treating them as safe.

The researchers' claims about real applications are wide. Wiz says it ran code remotely without authentication on the latest container images of WordPress, Drupal and Joomla, and that it could also leak passwords, tokens and API keys from memory without code execution. Calif lists pre-authentication code execution on WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS.

PHP 8.1 and older get no release from the project

The GitHub advisories list every branch below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 as affected, and the CVE records name only the 8.2 to 8.5 branches, with everything else marked unaffected by default. PHP 8.1 and older no longer receive updates from the PHP project. Its security team did publish minimal source backports for PHP 7.4, 8.0 and 8.1, aimed at people who build from source or have no long-term-support vendor, and Ubuntu shipped a patched PHP 8.1 package for its 22.04 release.

Researchers and security vendors date the exposure much further back. Wiz, Calif, Cloudflare and Imperva all put it back to PHP 5.4, Imperva noting that not every release has been tested. The CVE records' narrower scope therefore probably reflects the branches the project still supports rather than evidence that older ones are safe. That matters at scale: W3Techs counts 27.0% of PHP sites on version 7 and 7.7% on version 5, so the least-maintained installations may carry the longest exposure.

Even the supported range is short-lived at its bottom end. PHP 8.2 loses security support on December 31, 2026, about ten weeks after this fix, so sites patching onto 8.2.35 are likely to face another upgrade soon. Security support for 8.3 runs to the end of 2027, 8.4 to the end of 2028 and 8.5 to the end of 2029.

Most servers get the fix from a distribution or a host

Linux distributions and long-term-support vendors received the patches in advance, according to the PHP project. The SANS Internet Storm Center notes that most PHP sites do not run PHP built from php.net, so for them the race starts when their distribution ships. The version number can mislead. Ubuntu's USN-8948-1 covers 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10, and the fixed PHP 8.3 package for 24.04 reads 8.3.6-0ubuntu0.24.04.13, nowhere near 8.3.36, because Ubuntu backports the fix onto its older base. On distribution packages, the vendor's advisory or package version is a better guide than the upstream numbers.

Sites on shared or managed hosting are in a different position. Cloudflare points out that the flaws live in the PHP runtime, so updating site code or plugins alone does not fix them, and that managed-hosting customers should ask their provider to apply the update. WordPress told site owners to confirm their hosting provider's update plan and update PHP immediately. The PHP project also urged users of the volunteer-run rpms.remirepo.net repository to switch to distribution packages or build from source, because the repository would have no updates on release day.

Configuration changes narrow the attack paths without closing them

For servers that cannot be updated at once, the PHP project lists measures that "reduce exposure to specific attack paths but do not make an installation safe." Red Hat lists no mitigation that meets its criteria and says installing the fixed release is the only complete fix.

Against the out-of-memory flaw, the advisory recommends setting memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or the Apache configuration, and checking that nothing puts a finite limit back. It warns that an underlying allocation failure can still reach the vulnerable path, and Calif adds that removing PHP's memory cap raises the risk of memory exhaustion. Operating-system limits are no substitute: RLIMIT_AS and RLIMIT_DATA can themselves cause the vulnerable allocation failure. The project also recommends a post_max_size of 8M for applications without file uploads and 32M where uploads are needed, with upload_max_filesize kept below it.

Against the stale-state flaw, the advisory recommends turning off session.upload_progress.enabled and restarting every worker; a change made through ini_set() or an FPM .user.ini file does not count. That blocks the confirmed session paths but not other variants. On PHP 8.5, setting fatal_error_backtraces=0 blocks only the confirmed backtrace path, and hiding diagnostics with error_reporting, display_errors or the @ operator does nothing. The advisory says no generic configuration fully mitigates this flaw, because extension or server paths may plant or consume stale state without leaving a log entry, and it offers pm.max_requests=1 as an extreme option where performance does not matter.

Web application firewalls cover part of the gap. Cloudflare says its free and paid WAF customers have been protected by default since 3:02 a.m. UTC on October 21, while still telling them to patch. Imperva says its Cloud WAF customers are protected out of the box, while Elastic WAF and WAF Gateway customers need a software update first. CloudLinux says Imunify360's ModSecurity ruleset 8.83 blocks the circulating exploit pattern on Apache and Nginx with ModSecurity and on Coraza, but on LiteSpeed it only logs it, and calls the rules an interim mitigation. With Cloudflare reporting attackers reshaping payloads against its rules, a firewall alone looks like a thin defense. CISA also tells defenders to watch for PHP worker processes that launch shells or download tools, and notes that PHP is often embedded in other software.

The details leaked a day before the scheduled release

The PHP Foundation gave notice on October 20 of a security release for Wednesday, October 21, at 14:00 UTC, covering two critical flaws rated 9.2, and said it would release earlier if details became public or if there was evidence of active exploitation. Huntress says a post on the Hacker News forum on the morning of October 20 claimed two critical PHP vulnerabilities were headed for disclosure; it was taken down, but screenshots spread on social media. Benjamin Harris, watchTowr's chief executive, told BleepingComputer, in remarks relayed by PC Gamer, that the vulnerabilities were real, at a point when they were thought to rate CVSS 10 and to be under embargo until Thursday at 11 a.m. Eastern (15:00 UTC).

The Hacker News, relaying the PHP Foundation, reported that Calif mistakenly posted a video of its working proof of concept around 20:00 UTC on October 20, and that Chainguard published patched images about six hours before the fix shipped. Cloudflare also says the vulnerability leaked before the official release date. Huntress says the Wednesday slot was already a day earlier than the original embargo, and puts the release itself at around 9:30 a.m. Eastern (13:30 UTC), the same time CERT-EU gives. The php.net ChangeLog nonetheless dates all four releases October 22, a day after they shipped, and lists the fix as "Avoid state corruption via bailout."

Calif, Wiz and OpenAI tell the discovery differently

The official record shares the credit. The GitHub advisories list four reporters, lcfr-hax, sagitzadik-wiz, tomash-areion and amyb-oai. The CVE record for CVE-2026-109618 credits Wiz and "Ryan at Calif.io" as reporters and OpenAI as finder; the record for CVE-2026-109619 lists all three as reporters.

Calif said on X that the researcher lcfr_hax was the first to find php2shell and build a working exploit, pointing to an August 5 post. Calif says it reported the first bug to PHP on August 11, and that no special harness and no models unavailable to the public were used in the initial discovery. Wiz says it worked with the PHP team, Calif and OpenAI, that it used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout its research, and that with frontier AI a single researcher finished in a week what would previously have taken a world-class team months. OpenAI says Calif identified a critical flaw using GPT-5.6 Sol and that Wiz independently discovered and reported both flaws; it also says it led a two-month coalition of maintainers, researchers and security providers, and that PHP's maintainers led the fixes and the release.

The patch drops longjmp from PHP's out-of-memory handling

The fix goes to the root of the first flaw. It removes longjmp() from out-of-memory handling and replaces it with two steps: a soft out-of-memory error delayed to the next safe point in the virtual machine, and an immediate hard stop through _exit() at a second, higher threshold. OpenAI says the fix was intricate and needed a major change to the PHP engine. The bug class is old: Calif traces it to a remote memory-limit flaw Stefan Esser found in 2004, and The Hacker News reported that the PHP Foundation called its stalled response to a 2024 audit finding "a structural failure" of its decision process and its resources.

One piece of advice outlasts the update. The advisory for CVE-2026-109619 suggests that operators who don't need session upload progress keep session.upload_progress.enabled turned off even after patching, as more attackers will look for flaws in what it calls a "hardly-used and hardly-tested feature."