I asked 1,519 Canadian businesses one question, and 9 in 10 of the ones who answered said \"rob me\"

Picture this: PHP ships two bugs so nasty that its own advisory is essentially titled \"UPDATE NOW, PLEASE, WE'RE BEGGING.\" Each scores 9.2/10, which in vulnerability-speak translates to a stranger with no password can run their code on your server with one request. Not one request after a clever multi-stage dance. One. Request.

By Mackenzie Bowes · mackenzie@mackenziebowes.com · @_mackenziebowes on X

On 21 October 2026, PHP - the language quietly running 6 in 10 .ca websites - shipped fixes for two bugs so bad that PHP's own advisory is literally titled "Critical remote code execution vulnerabilities, update now." Each one scored 9.2 out of 10. Not "9.2, but it's fine." A 9.2 that means: a stranger with no password can run their code on your server with one request.

Not "one request after a clever multi-stage dance." One request. Their code runs as the same account your website runs under, which on WordPress means it can read wp-config.php, which is where you keep the database password, which means they can add themselves as an admin and redecorate your homepage at their leisure. They also get your domain - a nice trustworthy Canadian domain - to send phishing from.

The fix landed on 21 October in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Everything below that, on a plain upstream build, is exposed.

So I did what any well-adjusted person does with a fresh critical vulnerability: I checked whether anybody had actually updated.

The polite drive-by

I drew 2,000 Canadian businesses at random from the 47,331 in OpenStreetMap that list a website - shops, restaurants, clinics, trades, hotels - and sent each home page one request for its headers. After reading its robots.txt. I tried no exploit. This was less "hacker" and more "census taker with a curl command."

1,519 answered. Here's what they said:

• 44% run on PHP. Not a legacy niche. Nearly half the Canadian small-business web.
• 74% of those hide their PHP version. Good practice! Also means nobody outside can tell if they're patched. Schrödinger's website.
• Of the 173 that do show a version, 158 - 91% - were below the fix or on 8.1 or older, which PHP no longer fixes at all.

Read that again. The sites wearing name tags are overwhelmingly the ones with the problem. It's like a party where the only people who introduced themselves are the ones about to leave through a window.

I checked law firms too - 3,114 of them, same method. Of the 534 that showed a version, 484 were unfixed. Same 9-in-10. The legal profession and your local poutine place have identical security posture, which is not the kind of equality either group was hoping for.

And closer to home: I read every business OpenStreetMap lists with a website in Kelowna, West Kelowna, Lake Country, Kamloops, Vernon and Coldstream. 523 answered. Just 31 showed a PHP version, and 17 of those 31 were running pre-fix versions. The other 492? Unknown, not safe. Only their hosts can say.

Do the check yourself (two minutes, no skills required beyond copy-paste)

This is the fun part, and it's genuinely easy. Three places reveal a PHP version:

1. From outside, in a terminal (Windows users: type curl.exe):

curl -sI https://www.example.com

Look for a line starting x-powered-by: PHP/. In my sample, 5 of 6 PHP sites left it out - so if you see nothing, that's normal and proves nothing either way. But if you do see it, you've got a real answer.

2. On WordPress: log in as an admin, go to Tools > Site Health > Info, open Server, and read the PHP version line.

3. On cPanel: open MultiPHP Manager and it lists the version per domain.

Then the rules:

• Plain number at or above the fix for its branch (e.g. 8.2.35)? Patched. Congratulations, you're the 1 in 10.
• Plain number below the fix (e.g. 8.2.34)? Exposed. Send your host an angry-but-polite message today.
• Number with extra text after it, like 8.3.6-0ubuntu0.24.04.13? That's a Linux distribution's build, and here's the gotcha that will make you feel clever for knowing it: distros patch the old number instead of moving to the new one. So 8.3.6 from Ubuntu might be perfectly fine, while plain 8.3.6 from upstream is a disaster. If your host says "we're on 8.3.6 and we're patched," they might be telling the truth - ask for the full string with everything after the dash.

Not sure your site is even WordPress? View the page source and search for wp-content. If it's there, you're on PHP, and this whole post is about you.

The message that actually gets things fixed

On shared and managed hosting, your host decides when PHP updates, so the fix is one email. Copy this, swap in your domain:

Hi, my site is example.com.

PHP released fixes for CVE-2026-109618 and CVE-2026-109619 on 21 October 2026
(PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35).

1. Which PHP version does my site run, and does it include these fixes?
2. If not, when will it be updated?
3. Does my site run PHP as Apache mod_php, PHP-FPM or LiteSpeed?

Question 3 matters because the risk differs by setup - the full attack was demonstrated against Apache mod_php, which PHP calls the highest risk. And if your host offers settings tweaks like memory_limit=-1 instead of an update: PHP's own words are that those "do not make an installation safe." Ask for a date anyway.

Why this won't be the last one

Both bugs are memory-safety bugs in PHP's C core - one frees memory that was never set up, the other keeps pointing at memory after it's freed, and the next request trips over it like a rake left in the grass. This class of bug is everywhere: around 70% of Chromium's serious security bugs are memory-safety problems. And finding them is getting cheap - Anthropic's red team had Claude find and validate 500+ high-severity vulnerabilities in open-source code, and XBOW topped HackerOne's US leaderboard.

Translation: the next PHP advisory is coming, and it's coming sooner.

Which is why, when I build sites, they don't run PHP at all - this page is static files served as-is, no interpreter, no database answering your request. When a site genuinely needs code that runs per visit, I write it in Rust, where use-after-free doesn't compile. Android made a similar move and watched memory-safety bugs fall from 76% of its vulnerabilities to 24% in five years. The Canadian Centre for Cyber Security has been asking software makers to plan that move since 2023. It's not a fad; it's arithmetic.

Go run the check. It's fun. It's free. It's slightly haunting.

One curl command. One header. Maybe one very illuminating email to your host. And if you look after websites for a living and want a second opinion on your host's reply - or want to talk about never doing this patch dance again - write to me: mackenzie@mackenziebowes.com.

The next time a 9.2 lands, wouldn't you rather be the person whose site says "not my problem"?