PHP Ships Emergency Fixes for Two CVSS 9.2 Flaws That Need One Request

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 landed at 13:30 UTC on 21 October 2026, one day after the project announced an unscheduled security release. The builds carry fixes for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each scored 9.2 under CVSS 4.0. Both allow unauthenticated remote code execution, and public proof-of-concept code began circulating once the release went out.

Related reading: WordPress Patches Comment2Shell, a Comment Flaw That Can Lead to Server Takeover · Check Point Patches Two 9.8-Severity VPN Flaws That Allow Unauthenticated Code Execution.

Most web-facing bugs live in application code. These two live in the interpreter. A demonstrated exploit needs one request from an anonymous client, and it fires before a line of WordPress or Drupal executes. A patched plugin and a tuned web application firewall rule both sit downstream of the point where the attack lands.

Two ways to break a worker

The two bugs are unrelated in mechanism and land in the same place.

CVE-2026-109618, tracked as GHSA-w8hw-w9fx-j79w, is memory corruption during out-of-memory handling. PHP enforces memory_limit using longjmp(), which can interrupt a request while internal request data is only partly initialised. A multipart file upload is the example in the advisory. The cleanup path then treats invalid data as valid and frees memory that was never initialised, memory that can still hold attacker-controlled bytes left over from earlier allocations. Result: memory corruption an attacker can steer into code execution.

CVE-2026-109619, GHSA-6wmf-4rv5-p3rp, is stale global state. Internal state belonging to one request can survive after the memory backing it has been freed, with a fatal error given as one route. A later request handled by the same worker can read that stale state before normal initialisation overwrites it. The worker does not have to crash.

That dependence on worker reuse explains why the mitigation guidance keeps returning to restarts. Changing a setting in php.ini does not reach a worker that is already running with the old configuration, and neither does swapping the binary underneath it. The pool has to be recycled before either change takes effect.

Both bugs are rated 9.2, and both were reported to the PHP project before release, which is why distribution packages and long-term-support vendors had patches ready on day one. The PHP team published minimal source backports for PHP 7.4, 8.0 and 8.1 as well, a stopgap for branches that no longer receive official support.

Which server setups carry the risk

Every PHP installation that serves web requests is in scope. The PHP project lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and ranks mod_php as the highest-risk configuration of the five. No per-configuration exploitation data accompanied the advisory, so the ranking is a vendor assessment rather than a measured exploitation rate.

The install base is what makes the ranking consequential. W3Techs, cited by The Verge, puts PHP at 69.3 percent of all websites whose server-side language it can identify, a group that includes Wikipedia and WordPress. VirusTotal's scanner registers about 3.8 million sites running PHP with at least one port open. Unit 42's Cortex Xpanse telemetry produced a larger figure: over 22.6 million exposed instances potentially vulnerable.

Neither number counts confirmed exploitable hosts. "Potentially vulnerable" covers every address running a PHP version that predates the fix, including installs behind a proxy that blocks the relevant request shape and shared hosts that may already have patched the interpreter without telling their customers.

The Verge named 4chan, DeviantArt, Wikipedia and the blog of a local bar among affected sites. Kotaku reported that Pokémon Home and Pokémon Champions were taken offline. Some Dutch and Finnish government agencies pulled sites down as a precaution, and Unit 42 said at least one European government had done the same. Cloudflare's chief technology officer, John Graham-Cumming, told The Verge the company was "seeing early attacks emerging."

A 20-year-old bug that AI made practical

Wiz Research, which discovered and reported the vulnerabilities alongside the PHP project, says the underlying flaw had been in PHP for roughly 20 years.

Exploiting the bug "required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve." — Wiz Research

A bug can sit in a codebase for two decades without turning into a mass incident as long as the cost of building a working exploit stays above what most attackers will pay. Wiz attributes the change to AI models, which made it much easier to turn an obscure memory-handling defect into a working chain. Google, which owns Wiz, published its account on 21 October. OpenAI said separately that an AI security group called Calif identified a critical PHP flaw using GPT-5.6 Sol.

Two organisations using AI-assisted research arrived at the same interpreter-level defect, and the PHP project and Wiz disclosed together. That is one case, and one case does not settle how much AI shifts the balance between attackers and defenders.

What patching involves beyond the version number

For most sites the work is an interpreter update plus a restart, and the restart is where shared hosting gets messy. Long-lived PHP-FPM workers keep serving with the old binary until each one is recycled. Containers built on an old base image stay vulnerable until the image is rebuilt and redeployed. A control panel that reports PHP 8.3 does not prove the pool is running the fixed 8.3.36.

GoDaddy says any site using PHP should assume it is affected, and that applies to WordPress, Drupal, Joomla and Magento installations alike because none of those platforms ships its own interpreter. Updating a plugin or a theme changes files inside the application directory. It does not touch the binary that parses the request.

Two support gaps widen the tail. PHP 8.1 and older are end-of-life and will get no official build, so anyone still on 8.0 or 7.4 needs to upgrade or take a vendor backport. And the remi repository, a common source of newer PHP packages on Red Hat-derived systems, would not have updates on release day. The PHP team's advice was to switch to distribution packages or build from source.

What to do while the rebuild is queued

CERT-EU's advisory 2026-018 says the priority plainly: "CERT-EU advises organisations to patch affected assets immediately." If patching is not feasible, it says to isolate internet-facing applications from public networks until a fix is applied and verified. The NSA Cybersecurity account on X and the UK NCSC gave similar advice: take systems offline if an immediate update is not possible.

For organisations that cannot move that fast, CERT-EU lists temporary measures. They reduce exposure without closing the hole.

• For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration. Lower post_max_size to 8M without uploads and 32M with them. Enforce request-size, field and part limits at the proxy, and use a container or cgroup memory limit.
• For CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker. On PHP 8.5, set fatal_error_backtraces=0 and restart. Remove invalid per-request settings that emit diagnostics before initialisation, and fix fatal errors and timeouts that are reachable from outside.
• For both: patch, then restart. An updated binary on disk with workers still running the old one is not a fix.

What the numbers do not prove

The 22.6 million and 3.8 million figures are exposure estimates drawn from vendor telemetry and a survey. Neither is a count of hosts running code an attacker can reach.

Not every PHP-powered site is exploitable through the same technique. The bugs live in different subsystems, and the request shape that triggers one may not work against a given SAPI or a given set of options.

No confirmed mass compromise or attacker attribution had been published at the time of writing. Reports of sites going offline describe precautionary action as well as incidents, and the two are easy to confuse at this stage. Absence of a published mass compromise is not proof that none happened, only that no such finding had been made public on 21 October.

What to watch

The first signal is whether the proof-of-concept code becomes a commodity exploit. A working chain in public hands lowers the skill needed to use it, and PHP's install base gives anyone scanning an unusually large set of targets. Unit 42 said initial proof-of-concept code was circulating and that exploitation was likely.

The second is the end-of-life tail. PHP 8.1 stopped receiving official fixes, and 7.4 and 8.0 are further behind. Every site still on those branches is depending on a distribution maintainer or a hosting company to backport a memory-corruption fix, and whether one arrives depends on the vendor.

Then there is the research side. If AI-assisted work keeps producing interpreter-level bugs at this rate, the gap between a project publishing a fix and the long tail of unpatched servers applying it becomes the number that matters, not the CVSS score.

For now the sequence is short. Patch the interpreter, restart every worker, confirm the running version, and treat the exposure estimates as a reason to hurry rather than a measurement. Sites that cannot do it today should come off the public internet, which is what several operators already chose.

Cover image: "Custom-software-developement-php-net" by Ron23545, CC BY-SA 4.0, via Wikimedia Commons.