The patch that wasn’t for you

On 21 October the PHP project fixed two critical holes in the software that runs the booking form, the contact form and the admin login on an enormous share of small-business websites. For roughly a third of PHP sites, what arrived was not something they could install. Here is how to find out, in under a minute, which side of that line you are on.

How to check your PHP version in under a minute

Open your hosting control panel and look for a number under a heading like PHP version or Select PHP Version — cPanel, Plesk, or whatever dashboard your host gives you.

If your site runs WordPress there is a faster route: log in and go to Tools → Site Health → Info → Server, then read the line marked PHP version.

Then put the number in here.

If you cannot find the number at all, that is itself the result. Send one sentence to whoever maintains your site: “What PHP version is my site on, and was it updated on or after 21 October 2026?” A maintained site comes back with an answer the same day.

What happened on 21 October 2026

PHP is the language underneath most of the small-business web. You have almost certainly never thought about its version number, and there is no reason you should have. It is plumbing.

On 20 October the project gave advance notice of a critical security release. On 21 October it shipped PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two flaws that, in the project’s own words, “can allow unauthenticated remote code execution”. Unauthenticated means no password. Remote code execution means running their code on your server. The pair are CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2, and the security industry has been calling them PHP2Shell.

The same day, the European Commission, ENISA, CERT-EU, Europol’s EC3 and the network of EU national incident response teams issued a joint statement urging immediate patching. Five days later, on 26 October, the US Cybersecurity and Infrastructure Security Agency added both flaws to its Known Exploited Vulnerabilities catalogue — the list CISA keeps for vulnerabilities being used, not merely theorised about.

So the headlines were accurate: PHP was patched, quickly, and governments on two continents said so. Here is what the headlines left out.

Not everyone got the same fix

“PHP was patched” is one sentence covering three completely different experiences, depending on which branch your site already sat on.

If you are on 8.2 through 8.5, you got a numbered release. Your host can apply it from a control panel, and many did automatically.

If you are on 7.4, 8.0 or 8.1, something important happened that most of the coverage skipped. These branches are end of life and get no releases — but given the severity, the PHP security team published what it called “minimal source-backports” for all three, explicitly “to help people building from source or without access to an LTS vendor”.

That is a real, official fix. It is also source code. There is no release, no version number, and nothing your hosting panel can install. If you run a braiding studio on shared hosting, a patch you would have to compile yourself is, in practical terms, not a patch at all — which is exactly what this piece is about. The fix exists. It was not written for you.

If you are on 7.3 or older, or on PHP 5, nothing was produced. Those branches have been end of life for years.

Your website didn’t get safer on 21 October. Four versions of PHP did, and three more got source code.

How many sites are on an unsupported version?

PHP 8.1 reached end of life on 31 December 2025. PHP 8.0 on 26 November 2023. PHP 7.4 on 28 November 2022. The W3Techs technology survey, as of 2 November 2026, splits PHP-powered websites like this:

Add the three unsupported families together and you get 34.0% — my own arithmetic from those figures, not a number W3Techs publishes. About one in three PHP websites runs a major version with no supported branch at all.

And 34% is a floor, not a total. PHP 8.0 and 8.1 are both unsupported, and both sit inside that 66.0% “PHP 8” bucket. The survey does not break PHP 8 down by minor version, so the real unsupported share is higher than a third. I cannot tell you by how much.

Why so many sites are stranded on old versions

Not negligence. Drift.

A website gets built. It works. The person who built it moves on, or the arrangement quietly ends, or the plugin the whole booking flow depends on was last updated in 2021 and breaks on a newer PHP. So the version stays where it is, because moving it is the thing that might break the site, and the site working is the only thing anyone is measuring.

Then one Tuesday the version number stops being plumbing and starts being the story.

What an unpatched site actually costs a small business

Not “a data breach”. That phrase is for companies with a press office. For a braiding studio, a barbershop, a caterer or a cleaning service, it looks like this.

Your booking page goes down on a Saturday morning — your highest-volume day — and every client who tries to book sees an error instead of your availability. Your deposit link stops taking money, so the no-show protection you built your calendar around is gone for the weekend.

Or worse, and more common: nothing visibly breaks. Your site gets quietly used to host someone else’s spam pages. Google notices before you do, and your business name starts carrying a red warning screen in search results. Clearing that takes weeks, and during those weeks the thing a new client sees when they look you up is a warning.

And the client list. The names, the phone numbers, the appointment history sitting in your site’s database — all of it on a server where, on an unpatched version, a stranger can run code.

One more advisory nobody mentioned

Two days after the release, on 23 October, the project published a separate informational advisory about session upload progress, tracked as CVE-2026-115560. It has no fix in the 21 October release; the project’s recommendation is the configuration setting session.upload_progress.enabled=0 until a fix ships in a later release.

This matters because it cuts against the comfortable conclusion. Patching correctly on 21 October did not finish the job even for a fully supported site. If you have someone maintaining your site, that setting is worth one sentence in the same email.

The honest limits of all this

Four things I cannot tell you, and nobody honest can.

I cannot tell you whether anyone has touched your site. Remote code execution means an attacker can act. It does not mean anyone did act on yours. From the outside nobody can determine that — only logs can, and most small-business hosting keeps them briefly or not at all. CISA confirmed these flaws are being exploited. It published no victim count, and neither will I.

The 34% figure is softer than it looks. W3Techs publishes no sample size for that survey, revisits most sites only about monthly, excludes parked and throwaway domains, and states plainly that this kind of survey cannot be fully accurate because sites can conceal what they run. A site hiding its PHP version simply is not counted. Read 34% as “about a third”, not as a measurement.

“PHP runs 70% of all websites” is not what the data says. The W3Techs figure is 69.1% of websites whose server-side language is known — a different and smaller claim than 70% of all websites. The looser version is everywhere this week; it is still wrong.

And the one that costs me something. Owning your website does not mean it patches itself. I build sites where the client owns the domain, the hosting, the source code and every account outright, and I will defend that. But ownership is not maintenance. A site in your own name still needs someone to move the PHP version when a branch goes end of life — and on this one narrow question, a managed platform that upgrades PHP for you without asking has a genuine advantage. If your current setup did that for you on 21 October and you can verify it, that is a point in its favour. I would rather say so than pretend otherwise.

What you can actually control

Three things, in order.

One: know your number. You ran the check above. That is more than most business owners can say about their own site, and it turns an invisible risk into a specific question.

Two: know who moves it. Somebody is responsible for upgrading PHP on your site. It is you, your host, or a person you pay. If you cannot name which, that is the real finding of this article, and it is fixable this week with one email.

Three: know the dates. PHP 8.2 stops receiving security fixes on 31 December 2026 — about eight weeks from publication (my arithmetic: 2 November to 31 December is 59 days). PHP 8.3 runs to 31 December 2027, 8.4 to 31 December 2028, 8.5 to 31 December 2029. If you are on 8.2 you are currently patched, and you will not be in two months.

How I build

I build complete business websites — booking with deposits, an owner’s dashboard, mobile-first — where you own the domain, the hosting, the source code and every account in your own name. muriellehairbraids.com is one running live, taking real bookings and real payments.

What that buys you on the specific question in this article is not immunity. It is the ability to get an answer. You hold the hosting account, so the PHP version is something you — or anyone you hire — can read and change without asking a platform for permission. The scope is fixed and no part of your business sits behind a login somebody else owns.

Owning it does not make it free to run, either. The domain renews, hosting bills, payment processing takes its cut, and anything doing AI work has usage behind it. Those costs are real whoever holds the accounts.

Now send me your number

Find your PHP version, then send me just the number. Nothing else — no business name needed if you would rather not.

I want to see the spread, because I genuinely do not know what it looks like for small service businesses specifically, and the survey above does not break them out. If enough numbers come in, I will publish the distribution with no names attached.

This is the third time in six weeks I have ended up on the same question from a different direction — a WordPress patch in September, a Microsoft lifecycle date in October, and now a PHP branch. The pattern is not that software is dangerous. It is that somebody has to be watching the version numbers, and most small businesses have never been told that is a job.

Method and sources

What I corrected. My first draft said that for about a third of PHP sites “no official fix was published at all”, and that four versions of PHP were fixed on 21 October. Both were wrong. The project’s own advisory records that the security team also published minimal source backports for PHP 7.4, 8.0 and 8.1. That is a real fix, and it changes the claim from “nothing exists” to “what exists cannot be installed by the people who need it” — which is both accurate and the better version of the argument.

Primary sources, all read on their own pages on 1 November 2026. The release, the version numbers, the CVE identifiers, the CVSS rating, the source backports and every end-of-life date come from the PHP project (php.net). The joint statement is the European Commission, ENISA, CERT-EU, Europol EC3 and the EU CSIRTs network, 21 October. The exploitation status is CISA’s own bulletin of 26 October. The version distribution is the W3Techs survey of 2 November. No vendor blog, reseller post or listicle was used for any figure.

Mine, not any source’s. The 34.0% total (26.3 + 7.6 + 0.1), the phrase “about one in three”, the observation that 34% is a floor because 8.0 and 8.1 hide inside the PHP 8 bucket, and the 59-day gap between 2 November and 31 December 2026. W3Techs has never published 34.0%, and it should not be attributed to them.

Not claimed anywhere above: any count of sites actually compromised — no primary source publishes one; any assertion that custom-built code is inherently more secure than a platform; or any suggestion that an owned website has no running costs.

Common questions