Engineering

PHP shipped a critical fix. Old versions got none. Now what?

PHP fixed two critical flaws for 8.2 to 8.5 only. Most versioned PHP servers run older branches. Car recall law shows whose job the fix becomes.

Web code on a screen; illustrative, not PHP source. Photo by Florian Olivo on Unsplash

On 21 October PHP shipped emergency releases for two critical flaws, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10. Either can let an attacker run code on a web server without logging in. The project's own words: "We consider the risk highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs."

The fixes went to four branches: 8.2, 8.3, 8.4 and 8.5. For 7.4, 8.0 and 8.1 the PHP team posted minimal source patches, useful only to people who compile PHP themselves. For 7.3 and everything older, nothing.

A Shodan count published the day before, compiled by CybelAngel, found about 2.24 million internet-facing hosts advertising PHP. Of the roughly 1.5 million that report a version, 59% (883,717) run a branch with no official release. About 368,570 are still on PHP 5, whose last branch reached end of life on 31 December 2018.

2.24Minternet-facing hosts advertise PHP

59%of versioned hosts on a branch with no official release

368,570hosts still on PHP 5

4 yearsPHP support per branch; car recall duty: up to 15

Sources: CybelAngel, 21 Oct 2026, from Shodan counts by Mallory (20 Oct); php.net supported versions; 49 U.S.C. 30120(g).

So the question: when the fix exists but not for your version, whose job is it now?

Bar chart of internet-facing hosts reporting a PHP version: 8.2 to 8.5, 612,269, official fix on 21 October; 8.0 and 8.1, 185,789, end of life with source patch only; 7.x, 329,358; 5.x, 368,570, end of life since 2018 or earlier. 59 percent are on branches with no official release — Who got the fix. Source: CybelAngel, 21 Oct 2026, from Shodan counts published by Mallory; hosts, not websites.

Isn't this just people who should have upgraded?

That was my first reaction. PHP's policy is public. Each branch gets two years of full support and two more of security fixes, and then, in PHP's words, it "reaches its end of life and is no longer supported." Anyone on PHP 5 in 2026 has had almost eight years of notice.

20 Oct A Hacker News post leaks the coming disclosure; watchTowr confirms the flaws are real
21 Oct, 07:43 UTC Cloudflare's CTO reports early attacks
21 Oct, 13:35 UTC PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, about 25 minutes early
22 Oct, 11:00 ET The original embargo end

Source: CybelAngel timeline, 21 Oct 2026; iTnews, 21 Oct 2026.

Then I looked at who those hosts are. The count is of machines, not owners. CybelAngel notes that Amazon, Hostinger and Alibaba Cloud host the largest PHP populations, that shared hosting puts many sites behind one address, and that some Linux distributions backport fixes to old packages, so an old version number doesn't always mean an unpatched server. WordPress.org's own statistics, as reported, put 35.1% of WordPress sites on a PHP version the project no longer supports.

A lot of those site owners never chose a PHP version. They chose a host, or an agency, or a plugin. And the fix this time can't come from the place they usually look: updating PHP on the server is the only remediation, and no CMS or plugin update applies it.

"They should have upgraded" is true. It just isn't addressed to the people who will read it.

Who fixes a defect after the maker stops?

Cars answered this in law.

A mechanic working on a car engine — A mechanic at work; illustrative, not a Fisker repair. Photo by Sten Rademaker on Unsplash

In the United States, when a vehicle has a safety defect, 49 U.S. Code 30120 says the manufacturer "shall remedy the defect or noncompliance without charge." That duty lasts a long time. It only lapses once the car was "bought by the first purchaser more than 15 calendar years" before the recall.

And it survives the manufacturer going broke. When Fisker went bankrupt in 2024, its plan had Ocean owners paying the labour on two recalls, one of them a water pump that "can cause loss of power." The Justice Department, for the safety regulator, objected that splitting parts from labour has "no legal significance" and that bankruptcy "does not negate the manufacturer's duty." By the time the court approved the liquidation, owners could get the recall work done without paying for labour, with repair shops claiming from the trustee.

Who fixes a defect after the sale

A car with a safety recall (US)

Who must fix it the manufacturer, without charge
For how long until the car is more than 15 years past first sale
If the maker goes bankrupt duty survives (DOJ on Fisker, 2024)
Owner's job bring the car in

A PHP branch with a critical flaw

Who must fix it the PHP project, during support
For how long 4 years from release (2 full, 2 security)
If the branch is end of life no official release; source patches for 7.4 to 8.1 only
Owner's job upgrade, build, or ask the host or a vendor

Sources: 49 U.S.C. 30120; TechCrunch, 7 and 16 Oct 2024; php.net; CybelAngel, 21 Oct 2026.

Put the two side by side and the gap is plain. A car's defect stays the maker's problem for up to fifteen years, even through bankruptcy. A PHP branch's flaw stops being anyone's problem but yours four years after release.

Should PHP carry a recall duty, then?

I don't think so, and this is where the comparison has to bend. Fisker sold cars for money. PHP is given away. Asking its maintainers to patch every old branch for years would load a free project with a duty that, in cars, is paid for out of the price of the car.

What I'd borrow from the car rule is less the fifteen years and more who carries the duty: whoever sold the thing to the person exposed. In PHP's world, the nearest thing to a manufacturer for most end-of-life installs isn't the PHP team. It's the host that sold the hosting plan, the agency that built the site, the vendor whose appliance ships PHP inside. Some of them do act like it: distributions and paid long-term support vendors backport fixes. Many don't say anything at all.

That's an inference from how the market is built, not something anyone has measured. My guess is that a large share of the 883,717 will still be unpatched months from now, because the people who would have to act don't know they're the ones holding it.

I wrote two days ago about certificate keys that could be guessed in 256 tries, and before that about a cloud zone outage that took banks down. Same shape each time: the failure sits in a layer most of the people affected never chose and can't see.

If you run anything on PHP, the check is one line: ask whoever hosts it which PHP version serves your pages today, and whether their answer is 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or later, or a distribution package with the fix backported. If they can't tell you, you've learned who the manufacturer is.

The claim, in one sentence

Software has no recall law, so the day a version reaches end of life the duty to fix it moves from whoever made it to whoever runs it, and most of the people running it don't know they've inherited the job.

Established: The CVEs and fixed versions, PHP's support policy and end-of-life dates, the Shodan-based count and its limits, the recall statute and the Fisker outcome.
Inferred: That for most end-of-life PHP the host or vendor that sold the service is the nearest thing to a manufacturer.
Guess: That many of the 883,717 hosts stay unpatched for months.

More on Daily Ferment: Eight certificate keys could be guessed in 256 tries and The HFS bug was public for 11 weeks. The write-up got it exploited in a day..