PHP's Emergency Patches: What the PHP2Shell Flaws Mean for Every Site You Run

On 21 October 2026 the PHP project published emergency releases for two vulnerabilities in the language runtime itself. Both are rated 9.2 under CVSS v4.0, both allow an unauthenticated attacker to run code on a web server, and both affect every PHP branch still supported — plus versions going back more than a decade. If you operate WordPress, Drupal, Joomla, Laravel, Magento or a custom PHP service, this is the most urgent patching job of the year.

Two flaws in the language, not in your application

The important detail is where the bugs live. They are in PHP's core engine, in the way it handles fatal errors and cleans up memory between requests, not in a plugin, a theme or a framework. That means the usual advice — keep your CMS updated, audit your extensions — does nothing here. A plain PHP script on an affected version is exposed, and so is a carefully written application.

Wiz Research, which found and reported the issues, demonstrated unauthenticated remote code execution against then-current container images of WordPress, Drupal and Joomla. A second impact matters just as much: the same flaws can leak the contents of a PHP worker's memory, which may hold passwords, session tokens, API keys and TLS certificates belonging to other requests handled by that process.

What the two bugs actually do

CVE-2026-109618 is corruption during out-of-memory handling. PHP uses `longjmp()` to abort a request when memory runs out, and in some code paths request memory is briefly reachable before it is fully initialised. If an allocation fails at that moment, the shutdown routine can treat invalid data as valid. Several multipart parsing tricks let a request reach the memory limit while staying inside its declared limits — a multipart body without a usable content length, or a part with a very large number of headers.

CVE-2026-109619 is a use-after-free across requests. Some worker-level state — error, session, object and extension state — points at memory owned by a single request. If a fatal error or timeout interrupts cleanup, that state survives after the memory is freed, and an operation in the next request can consume it. PHP calls this a producer and a consumer pattern: one request leaves the stale pointer, a later one acts on it. The advisory lists memory disclosure as a confirmed impact alongside code execution.

The stale-state advisory notes that exploitation needs a strategically crafted heap layout, which is part of why flaws like these sat undiscovered for so long. It is also why the CVSS score matters more than the difficulty: 9.2 is the vendor's own rating, and the identifiers that leaked before release carried an incorrect 10.0.

Which versions are affected

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Everything from PHP 5.4 up to 8.5.11 is affected by at least one of the two flaws.

End-of-life branches are the uncomfortable part. PHP 8.1 and older will not receive official releases. Because of the severity, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for teams that compile from source or have no long-term-support vendor. For 5.4 through 7.3 there is no fix from the project at all, and no configuration change makes those versions safe.

PHP 8.2, the oldest branch that got a patch, reaches end of life on 31 December 2026. Any site still on it has a second migration deadline in ten weeks.

The patch arrived a day early because the details leaked

The release was originally scheduled for 22 October. On 20 October the PHP team issued an advance notice, moved the release forward to 21 October at 14:00 UTC, and said it would go earlier still if details became public or exploitation appeared. They did: the CVE identifiers circulated on Hacker News and social media that day, and a technical write-up of the exploit chain, nicknamed php2shell, followed from Calif.io.

Two practical notes from the announcement. Linux distributions and LTS vendors had the patches in advance, so distribution packages are the fastest route for most servers. The volunteer-maintained `rpms.remirepo.net` repository, used by many CentOS and AlmaLinux setups, did not have the updates on release day; the PHP team urged those users to switch to distribution packages or build from source. And a PHP upgrade is not finished until the workers are restarted — opcache and long-running FPM pools will keep serving the old binary otherwise.

The attacks started before the announcement

Amazon Threat Intelligence reported an exploitation attempt against its MadPot honeypot network on 17 October, four days before public disclosure, and said it could not tell how the attacker obtained exploit information. More attempts followed on 21 October, with payloads and infrastructure suggesting several different actors. Amazon's assessment is that php2shell is now being broadly exploited in the wild, and it recommends starting incident investigations from 17 October rather than from the disclosure date.

Cloudflare's CTO Dane Knecht said the company was seeing early attacks and updating mitigations as new vectors appeared. The security firm watchTowr said it had reproduced both vulnerabilities and was observing exploitation attempts against both. CERT-EU published an advisory the same day, noting that proofs of concept were beginning to circulate.

Scale estimates vary and should be read as rough. Security researcher Silas Cutler put the number of potentially vulnerable internet-exposed hosts above 1.3 million; a Shodan count cited by Henk Poley put internet-exposed PHP hosts at over 1.9 million. W3Techs has PHP on 69.3 percent of websites whose server-side language is known.

Why mod_php is the riskiest setup

PHP lists every installation that serves web requests as at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It singles out mod_php as the highest risk, because with Apache's embedded module the vulnerable sequence can occur during request startup, before any application code runs. That removes the layers of application-level validation people tend to count on.

The advisories document a validated PHP-FPM path as well for CVE-2026-109619, so switching to FPM is not a substitute for patching — it only changes which attack path is available. Checking which SAPI you actually run is still worth the two minutes, because it tells you how exposed you are while you schedule the upgrade.

If you cannot patch today

PHP is direct about this: only an update is a complete fix, and the measures below reduce exposure to known paths without making an installation safe.

For the out-of-memory flaw, the primary stopgap is setting `memory_limit=-1` administratively, for example through `php_admin_value` in the FPM pool or Apache configuration, and then confirming no pool, directory or application setting restores a finite limit. Keep `post_max_size` low — 8 MB where file uploads are not needed, 32 MB where they are — with `upload_max_filesize` below it, and enforce request-size, header-count and nesting limits at the proxy as well. A container or cgroup memory limit can act as an availability boundary, but PHP warns against substituting `RLIMIT_AS` or `RLIMIT_DATA`, which can themselves trigger the vulnerable allocation failure.

For the stale-state flaw, set `session.upload_progress.enabled=0` and restart every worker, using configuration that applies before request parsing rather than `ini_set()` or `.user.ini`. On PHP 8.5, also set `fatal_error_backtraces=0`. Remove per-request settings that emit diagnostics before initialisation, and fix any attacker-reachable fatal errors or timeouts. Hiding messages with `error_reporting` or `display_errors` does not help.

At the edge, Cloudflare has deployed WAF rules for the known exploit vectors to all customers, including the free plan. AWS suggests its `SizeRestrictions_BODY` rule for request bodies over 8 KB. Fastly, Imperva, Akamai and Vercel published similar guidance. Treat all of it as time bought, not protection.

What the discovery says about AI and security

Wiz found these bugs with its own Atlas tooling alongside Gemini 4 Argon and GPT-5.6 Sol; Calif found one of them through OpenAI's Patch the Planet programme with GPT-5.6 Sol. Wiz's account is that a single researcher did in a week what would previously have taken a strong team months, because the models could adapt an exploit to different memory layouts and configurations and iterate through testing and debugging.

The defensive reading is not that AI suddenly made PHP insecure. It is that exploit development has become cheaper, so the old assumption that a bug is too intricate for anyone to weaponise no longer holds. If the cost of turning a decade-old memory-safety flaw into a working exploit keeps falling, the practical window between disclosure and exploitation keeps shrinking, and patch cadence has to follow.

A checklist for this week

Start with inventory, because it is the part that always takes longest. List every PHP version you run: application servers, container images, staging environments, build agents, and vendor appliances that embed PHP without advertising it. CERT-EU points to the NCSC-NL repository for tracking third-party software that bundles PHP.

Patch to the fixed release for your branch, then restart PHP workers and clear opcache. Where a host is on 8.1 or older, check whether your distribution or LTS vendor has a backport; if not, the migration is the fix.

Review logs from 17 October onward for multipart requests with odd content lengths, header floods and OOM-triggering traffic, and rotate credentials that live in any environment that ran an affected version while internet-facing. Memory disclosure means a token in that worker's memory may already be somebody else's.

Finally, put the 8.2 end-of-life date on a calendar. Two critical runtime bugs in one release cycle is a good argument for not being on a branch that stops receiving fixes in December.

The patch itself is a download and a restart. The inventory behind it is the real work, and this week is the week to finish it.