PHP2Shell: Two Critical PHP Flaws Patched, What to Do Now

On October 21, 2026 at 14:00 UTC, a day earlier than planned, the PHP project shipped four security releases, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, to close two critical vulnerabilities that its advisory says "can allow unauthenticated remote code execution". The CVE identifiers are CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. Wiz Research, which found the bugs independently of the Calif team that first reported them on August 11, calls the pair PHP2Shell. If you own a PHP site, pay someone to host one, or build on WordPress, Drupal, Laravel or Magento, the only complete fix is a PHP update, and the project's own release notes say so in one line: "There are no complete mitigations, updating is the only safe choice."

This post covers the release, not the strategy. Where the patch comes from on a managed host, a distro package or an end-of-life PHP branch is a separate question, answered in our PHP2Shell fix table by distro, control panel and PHP version. What this week should change about how a business patches is in website security after PHP2Shell. Here we stay with the facts of October 21: what shipped, who is in scope, what the interim settings actually do, what is known about exploitation as of our check, and how the bugs were found. Sources were read on October 21 and 22, 2026 (CEST), and each claim names its source.

The PHP security advisory is short and worth reading in full, because most of what matters is in it. Four supported branches received a release. Each release note says the same thing: a security release fixing two critical vulnerabilities, update immediately. The 8.2 note adds a date that matters for planning: PHP 8.2 reaches end of life on December 31, 2026 and will receive no further security fixes after that, so an 8.2 site is buying about ten weeks with this update, not a year.

Older branches are covered differently. PHP 8.1 and earlier get no release from the project. Instead the security team published what it calls minimal source backports for PHP 7.4, 8.0 and 8.1 as branches on GitHub, aimed at people who build from source or have no LTS vendor. The advisory also says Linux distributions and LTS vendors received the patches in advance, and singles out one volunteer package repository, remirepo, which it says would not have updates on release day and urges users to move to distribution packages or source builds.

The honest answer is almost everyone running PHP on the public internet. The advisory's own scope line is "all PHP installations serving web requests", and it lists the server integrations by name: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The team rates the risk highest for mod_php, the module that embeds PHP inside Apache, because it has a demonstrated exploit in which an unauthenticated request triggers the bug before any application code runs. A login page, a firewall rule in your app, or a hardened theme does nothing in that case, because the attack lands below them.

Wiz's research post widens the version picture. Its authors write that every PHP version released in the last decade is affected by at least one of the vulnerabilities, back to 5.4, and that the flaws sit in the engine rather than in any application. Their demonstration used the then-latest official container images of WordPress, Drupal and Joomla and achieved unauthenticated code execution on each. Calif's write-up lists a longer set it reports pre-authentication code execution against, including MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS at specific recent versions. The failure case to understand is the quiet one: Wiz also demonstrated an unauthenticated memory disclosure that returns a slice of live worker memory, which it says can contain passwords, tokens, API keys and certificates belonging to other requests. A site can be read without being visibly broken.

One number needs its label. Wiz's headline says PHP2Shell affects "70% of the Internet", drawing on the common statistic that PHP "powers 70% of all websites in the world". That figure is Wiz's framing of a server-side language share; we have our own view of the WordPress and PHP share data and the point survives any reasonable estimate. The population is tens of millions of sites, which is why infrastructure vendors were briefed in advance.

The advisory describes each bug in two sentences, and the descriptions are enough to understand why the interim settings look the way they do. CVE-2026-109618 is labelled "RCE via OOM corruption". When a request runs PHP out of memory, PHP can be interrupted while its internal request data is only partly set up, and the cleanup that follows may treat that half-built data as valid. An attacker who can make a request hit the memory limit at the right moment gets a say in what the cleanup does.

CVE-2026-109619 is labelled "RCE via stale global state". Some request-owned internal state can outlive the memory that backed it, and a later request handled by the same worker process can use that stale state before normal initialisation resets it. That is why Wiz describes cross-request and cross-worker effects, and why the disclosure variant can leak data from someone else's request. Wiz's technical write-up groups several specific chains under the two identifiers, including a use-after-free in the session upload progress code, a second in the fatal-error backtrace feature that only exists in PHP 8.5, and an OPcache type confusion it used against WordPress. The PHP Foundation adds the detail that the out-of-memory bug reaches mod_php before application code and was confirmed on PHP-FPM through application-level code paths.

This is the part of the story that will date fastest, so the table gives each statement with its source and the time we read it. We checked the CISA Known Exploited Vulnerabilities catalog directly through its JSON feed. The feed carried a release stamp of 14:04 UTC on October 21 and, when we read it at 20:44 UTC, listed 1,754 entries, none of them either PHP CVE. The newest entries were dated October 20. That is a statement about the catalog at that moment, not a statement that no exploitation has occurred.

Cloudflare's post says its managed WAF rules went live at 03:02 UTC on October 21, on every plan including Free, and that the company "observed attack traffic targeting our customers" with attackers "mutating the attack payload" to get past the rules. It gives no counts or timestamps for that traffic. The PHP Foundation's post, written for release day, says the team found no functional exploits public at the time of release. Those statements are compatible: attempted traffic against a WAF is not the same as a working public exploit. CISA's own enrichment of both CVE records, added at 14:34 UTC on October 21, rated exploitation "none" in its SSVC assessment; that is a point-in-time judgement too.

The advisory lists configuration changes for people who cannot update immediately, and it frames them precisely: they reduce exposure to specific attack paths but do not make an installation safe. Calif's write-up says the same in fewer words, that the changes do not replace a patch. Read them as a way to narrow the window between now and the update, and note that the advisories ask for these settings to be applied where applications cannot override them, followed by a restart of every worker.

For the out-of-memory bug, the advice is to set the PHP memory limit to unlimited, enforced through an admin value in the FPM pool or Apache configuration so no application can put a finite limit back. That removes the controllable memory-limit failure, with the stated caveat that an underlying allocation failure can still reach the vulnerable path. Alongside it, cap request size: an 8M post limit where no uploads are needed, 32M where they are, upload size below the post limit, and limits at the web server or proxy for decoded request size, field count, multipart part count, header count and nesting depth, including for requests with no usable content length. Use a container or cgroup limit as the availability boundary, and specifically do not substitute the RLIMIT_AS or RLIMIT_DATA process limits, because those can cause the very allocation failure the bug needs.

For the stale-state bug, disable session upload progress in php.ini or pool configuration and restart the workers. The advisory says not to rely on a runtime ini_set call or an FPM .user.ini file, because those apply too late. On PHP 8.5 also disable fatal error backtraces. Then remove any invalid or deprecated per-request settings that emit diagnostics before initialisation, and fix any fatal errors or execution timeouts an attacker can reach. The example that trips people up is the last one: hiding diagnostics with error_reporting, display_errors or the @ operator does not help, because the problem is that the error happens, not that it is shown.

A WAF belongs in the same category. Cloudflare's rules check both the request and the origin's response and can block a response before it reaches the requester, which is more than a simple request filter can do. The same post still tells customers to patch PHP with the protections left on, and states that restricting uploads and limiting upload sizes do not replace the PHP fix. That is the right order of operations for anyone: keep the shield up, and update behind it today.

Calif and Wiz found the bugs independently, both with frontier AI models in the loop, and the PHP Foundation also credits a same-day report from OpenAI. Calif, a small research group, joined OpenAI's Patch the Planet initiative and began auditing PHP around July 30, 2026, by its own account not expecting to find anything critical. The first critical bug surfaced on August 1. Calif reported it to PHP on August 11, shared a working proof of concept on August 14, had it confirmed on August 15, and reported the second bug on August 21. OpenAI's coordination post says Calif used GPT-5.6 Sol; Calif's own write-up describes an LLM "audit buddy" agent for source review and a reusable pattern written into a skill file, with no special harness or restricted model access.

Wiz Research came at it separately. Its post dates the first discovery to August 19, using Wiz Atlas together with Gemini 4 Argon and GPT-5.6 Sol, confirms unauthenticated code execution against Drupal on August 20 and WordPress on August 21, and reports to PHP on August 24; by Wiz's timeline, PHP acknowledged its reports on September 21. The PHP Foundation's post records the same August 11 date for Calif's report, says OpenAI independently reported the same root cause that day, and says fixing it was the security team's top priority from August 11 onward. Calif's and Wiz's timelines describe two groups arriving at the same place a fortnight apart.

The claim that matters for the rest of the industry is in the same Wiz post: building a working exploit meant chaining several flaws and adapting to each target's memory layout through repeated testing, and the models made it practical to develop and adapt exploits across applications "in hours". OpenAI's post makes the other half of the argument. It says that to its knowledge, frontier AI found these vulnerabilities before attackers did, and that it expects similar findings "to increase sharply in the coming months". The PHP Foundation puts a number on the load that creates: the security team has published 15 CVEs since July 1 and handled more than 100 reports that were invalid, duplicates or not reproducible. Our write-up of a vendor-published AI disclosure ledger covers the same pattern across hundreds of open-source projects.

The release was planned for October 22. It happened on October 21 because the embargo failed in stages, and the PHP Foundation's post lays out the sequence in UTC. Around 15:00 on October 20 both CVE identifiers circulated online with a wrong release time and a wrong severity score; the leaked score was 10.0, and the Foundation says the actual score is 9.2. No technical detail leaked at that point. At 19:30 the project published its advance notice early, with the release date already moved forward to October 21 at 14:00. Around 20:00 Calif mistakenly published a video showing its proof of concept against several targets; it was deleted, but copies spread. Mitigation advice the Foundation began sending to a few critical infrastructure providers around 23:00 may also have leaked.

Then, at 07:41 on October 21, Chainguard published container images containing the fix, more than six hours before the release. The Foundation says that disregarded weeks of coordinated work by many parties. Cloudflare's rules had gone live at 03:02, which in hindsight was fortunate ordering. The Foundation calls the one-day move the best compromise between acting quickly, giving people time to prepare and keeping a simple update path for everyone, and the advance notice reserved the right to release earlier still. The lesson for anyone who runs a site is unglamorous: when a project posts a dated critical pre-announcement, put an engineer on standby for that hour, because the hour can move.

The routing below is the advisory's guidance sorted by the reader. Two things apply to everyone. First, confirm what you are actually running, and do not trust the bare PHP version string to tell you. Distributions and control panels often backport a security fix without changing the upstream version number, so a server can report 8.3.6 and still carry the fix inside its package build, or report a fixed-looking number from a different pool than the one serving your site. The check that counts is the package or build version your distro, panel or host lists as fixed, read against the package actually installed. OpenAI published a version checker as a Codex skill to help map versions to the right update; use it as a starting point, not a verdict. Second, if an exposure window existed, assume the memory disclosure variant could have been used, and rotate the credentials a worker could have held in memory, which means database passwords, API keys and session secrets. Wiz says that memory can hold passwords, authentication tokens, API keys and certificates.

Related deadlines stack this week. Anyone whose stack also includes a Next.js front end should note that Next.js 15 left its maintenance window on the same day, and WooCommerce stores had their own security release in August. None of those is a reason to delay the PHP update; PHP is the layer the others run on. If your team does not have the hours this week, our web development team patches and verifies PHP estates for clients as a standing service.