PHP patched two critical flaws while half of PHP sites stayed on old branches

PHP patched two flaws rated 9.2 on 21 October. W3Techs data implies 48.5 percent of PHP sites run branches the project no longer patches.

The PHP project shipped fixes on Wednesday 21 October for two flaws. Each lets an unauthenticated visitor run code on a web server.

About half of PHP sites run branches the project no longer patches. Their fix must come from a vendor or a migration. PHP runs 69.3 percent of the sites whose server language W3Techs can identify, leaving a large exposed base.

W3Techs' 21 October tables split PHP sites two ways. PHP 7, 5 and 4 run 34.8 percent. PHP 8.0 and 8.1 add 13.7 points. That is 48.5 percent on branches PHP has stopped patching.

The other half can patch. It runs 8.2 to 8.5, where PHP's security notice lists releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The sites without a project fix are about a third of all sites with a known server language. That is 48.5 percent of the 69.3 percent PHP share, a large base for any attacker holding a working exploit.

The project did publish minimal source backports for 7.4, 8.0 and 8.1. A backport is a fix copied onto an older version. PHP says some distributions and long term support vendors ship their own backports. Those vendors sell fixes for old versions; PHP tells users to ask them.

Both flaws sit in the PHP engine, not in an application. Calif reported the chain to PHP first, on 11 August. It and Wiz Research both describe PHP cleaning up badly when a request runs out of memory. Leftovers from one request then carry into the next on the same worker, the process that handles web requests.

GitHub's advisory for CVE-2026-109618 scores it 9.2 out of 10, critical, on the CVSS severity scale. It needs no privileges, and it confirms code execution as the account the web server runs under. The second flaw, CVE-2026-109619, also carries 9.2.

The maintainers say all installations serving web requests are exposed. They rate the risk highest for mod_php, a way of running PHP inside the web server. There a demonstrated exploit fires before any application code runs.

Attack complexity is rated high, so an attack needs the right conditions. The score still reaches 9.2 because no privileges are needed.

The default settings are the trigger. Calif shows that a request under the default 8 MiB size limit can hold hundreds of empty upload records. Together they overflow the default 128 MiB memory limit. The limits meant to contain a bad request are what let it through.

The interim advice is limited. Both PHP and Calif say to remove the memory cap, which PHP itself calls partial. PHP adds that "there are no complete mitigations, updating is the only safe choice."

Cloudflare chief technology officer Dane Knecht calls his company's firewall rules a stopgap. A firewall rule filters bad traffic before it reaches the server. The bug stays in the engine.

The bug class is old. Calif traces it to a 2004 observation by Esser and a bug reported in 2020 as number 78876. A 2024 audit by OSTIF and Quarkslab found a related bug but called exploitation unproven.

Nobody could show that report working, so it stayed open. What changed in 2026 was the cost of showing it.

Proof became cheap quickly. Calif dates its discovery to 1 August, a first report to PHP on 11 August and a second bug on 21 August. Patches arrived 71 days after the first report.

Attackers had a head start. Security firm Sansec publishes a timeline. It says the details leaked on 20 October and that Cloudflare reported early attacks at 07:43 UTC on release day. Cloudflare's own post says its firewall rules went live about nine hours before public disclosure and still tells customers to patch.

The same firm says technical write ups and an exploit tool are public, so it expects mass exploitation. The CISA catalogue of exploited flaws did not list either flaw at its 14:04 UTC update on 21 October. Several Dutch sites, including Tweakers, the House of Representatives, the NCSC and Security.NL, went offline as a precaution on 21 October.

Wiz says one researcher finished in a week what once took a world class team months. It names Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol as the models its team used. Wiz compares the episode to Heartbleed in 2014 and Log4Shell in 2021, two earlier internet wide emergencies.

Calif tells a more modest story. It reports no special harness or unreleased models, and no model that finds every bug from a simple prompt. Its finder also knew the history, and that history made the models useful.

Ignoring an old bug class is no longer cheap. While proof took months, a 20 year old class could sit unproven. The 2020 report shows how long such a bug can sit in a public tracker before someone proves it.

PHP 8.2 itself loses security support on 31 December, so its 18.1 percent of PHP sites have ten weeks of cover. Security support means the project still ships fixes.

Sites on packaged builds face a second gap. PHP urges users of the volunteer maintained Remi repository to switch to distribution packages or build from source. Then they can apply updates at once. A hosting plan on PHP 7.4 has no official release to wait for.

An agency or host with many client sites has three options. Moving the 8.1 and older estate to 8.3 or 8.4 is the clean answer, though it needs plugin and theme compatibility testing.

Buying backports from a long term support vendor is cheaper in the short run. But the vendor, not PHP, then owns the fix timeline.

Blocking multipart form data at the web server, the format browsers use for file uploads, is the security firm's stopgap. It buys days and breaks every file upload. A move to 8.2 is a poor use of a migration, since it only buys ten weeks.

The unpatched tail is where attackers with a public exploit tool will look first. By 31 December PHP 8.2 loses its security support, and mass exploitation is likely well before then. Any estate still on 8.1 or older will rely on vendor backports until it migrates. The only other cover is a firewall rule its own author calls a stopgap.