The PHP Flaw That Put Most of the Web at Risk: What It Means for Your Website

On 21 October 2026, the PHP project did something it very rarely does. It stopped the normal release schedule, gave the world about twenty-four hours’ notice, and shipped an emergency security release for every supported version at once.

If you own a website, you probably heard nothing about it. If you are on decent hosting, your host patched the server and you were never at risk for long. But it is worth understanding what happened, because this one touched a bigger slice of the internet than almost any website bug in recent memory, and because it says something uncomfortable about how fast attacks move now.

What Actually Happened

PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two separate flaws in the language itself. Both were rated 9.2 out of 10 on the CVSS severity scale, and both allowed what security people call unauthenticated remote code execution.

In plain English: an attacker who had never logged in, never had a password and never had an account could potentially get the server to run their code. Not the website’s code. Theirs. Researchers nicknamed the pair PHP2Shell, because the end result is an attacker getting a shell, a command line, on your server.

Two days later, on 23 October, the team published a further informational advisory about session upload progress (CVE-2026-115560), recommending that it be switched off until the next routine release. On 26 October, updated Windows builds went out to pick up a separate fix in the Brotli compression library.

Why This One Matters More Than Most

Most website security stories involve one plugin, used by a few thousand sites. This was different, because of what PHP is.

PHP is the language the majority of the web is written in. According to W3Techs, it is used by roughly 70% of all websites whose server-side language is known. It is not a fashionable choice and most business owners have never heard of it, but it is the thing quietly running underneath an enormous share of the internet.

And then there is WordPress, which is written in PHP. W3Techs puts WordPress at 39.5% of all websites and 58.2% of every site running a known content management system. So when a flaw turns up in PHP itself, it does not affect one plugin or one theme. It potentially affects every WordPress site, every Laravel application, every Joomla and Drupal site, every bespoke PHP system a developer built a decade ago and nobody has touched since.

“My Site Is WordPress — Doesn’t a WordPress Update Fix It?”

No, and this is the part people get wrong.

The flaw is not in WordPress. It is one level below WordPress, in the engine WordPress runs on. You can update WordPress core, every plugin and every theme, see a reassuring row of green ticks in your dashboard, and still be sitting on a vulnerable server. There was no WordPress update that fixed this, because there was nothing in WordPress to fix.

The fix lives with whoever controls the PHP runtime on your server. For most small businesses that is the hosting company, and the good ones moved quickly. The large managed WordPress hosts had patched builds out on the day. Shared hosting that runs CloudLinux rolled patched PHP builds into their version selectors. If you are on a VPS or a server somebody set up for you years ago and nobody has logged into since, that is where this gets uncomfortable, because nobody patched anything unless they did it by hand.

The Part That Should Worry You: The Gap Has Collapsed

Here is what made this different from the same story five years ago.

The patch went out on 21 October. By 26 October, the US Cybersecurity and Infrastructure Security Agency had added both flaws to its Known Exploited Vulnerabilities catalogue, which it only does when something is being used in real attacks, and gave federal agencies until 29 October to patch. One researcher running honeypots, deliberately vulnerable servers set up to watch attackers, reported dozens of successful shell executions against PHP 8.4.26 within days.

Five days from public patch to confirmed mass exploitation. That is now normal, and it is getting faster.

CrowdStrike’s 2026 Threat Hunting Report found that 88% of the exploitation it observed against flaws with public proof-of-concept code happened within 48 hours of that code being released. Synack’s 2026 research describes attackers exploiting newly disclosed flaws within hours, where in 2022 the same process took weeks.

The honest explanation is that a lot of this is automation, and increasingly AI-assisted automation. Writing a working exploit from a patch used to be slow, skilled, manual work. Now a great deal of that work — reading the patch, working out what it changed, building something that abuses it, then scanning the whole internet for servers that have not updated — can be done by tooling, at machine speed, against every site at once. Security researchers are careful to say the collapse in timelines correlates with the rise of this tooling rather than being proven to be caused by it. Either way, the practical effect for a business owner is the same.

Nobody is targeting your plumbing company in Cornwall. That was never how this works. Automated scanners sweep the entire internet looking for servers that have not been patched yet, and your site is simply one of the addresses on the list. Being small has never been protection. Being patched is.

What To Do This Week

None of this needs you to become technical. It needs you to ask three questions and get real answers.

• Ask your host what PHP version your site runs, and confirm it includes the October fixes. You want a straight answer naming a version: 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later. “We are aware of the issue” is not an answer.
• Check whether you are on a PHP version that still gets fixes at all. PHP 8.2 reaches end of life on 31 December 2026, and anything older than that has been unsupported for a while. If your site is on PHP 7.4 because a plugin broke on 8 and nobody ever went back to it, that is a real problem that this has simply made visible.
• If you manage your own server, patch it, do not mitigate it. The PHP team said plainly that the partial workarounds do not make an installation safe.
• Have a quick look for anything odd. Administrator accounts you do not recognise, files in your uploads folder with a .php extension, unexpected redirects for visitors arriving from Google. If anything looks wrong, get someone to check properly rather than deleting things and hoping.
• Make sure you actually have a backup you have tested. Not “the host probably has one”. One you know exists and know how to restore.

So Is It Time To Leave WordPress?

I would be doing you a disservice if I used this to tell you WordPress is broken, because that is not what happened here. The flaw was in PHP, and a bespoke PHP application would have been exactly as exposed as a WordPress site. WordPress was not the weak point. It was simply standing on the thing that broke.

What is fair to say is this: the more moving parts your website has, the more often this will happen to you, and the more it depends on somebody staying on top of it. A WordPress site is PHP, plus a database, plus a theme, plus however many plugins, each of which is its own small ongoing risk. That is a perfectly reasonable trade for what WordPress gives you — a proper content editor, a huge ecosystem, the ability to change things yourself — as long as someone is actually maintaining it and your hosting is run by people who patch quickly. Badly hosted, un-updated WordPress is the problem. WordPress is not.

The alternative is worth understanding, though. The sites I hand-build are static: HTML, CSS and JavaScript, served straight from the server with no PHP runtime, no database and no plugins. There is nothing on the server executing code when somebody visits, so this entire class of vulnerability does not apply. That is not me being clever. It is just a different trade: fewer moving parts and a much smaller attack surface, in exchange for changes coming through me rather than through a dashboard, which is why changes within 48 hours are part of what I do.

If you want the long version of that comparison, I wrote it up separately in WordPress vs custom coded, and there is more detail on how each is built on the WordPress and custom-coded pages. Neither is the right answer for everyone.

The Short Version

A critical flaw in the language most of the web is written in was patched on 21 October 2026 and was being actively exploited within five days. No WordPress update fixed it, because the problem was underneath WordPress. The only real fix was the hosting company updating PHP.

If you can get your host to confirm, in writing, which PHP version your site is on and that it includes the October patches, you have done the important part. If you cannot get a straight answer out of them, that tells you something worth knowing too.