6 in 10 Canadian websites may be at critical risk right now from two PHP bugs (CVE-2026-109618 and CVE-2026-109619) - why, how to check yours in two minutes, and what to do

If your website runs on WordPress, a stranger with no password may be able to take it over right now with one request, along with everything your clients have typed into it. The two PHP bugs that allow it were fixed on 21 October 2026, and your site stays open until your host installs the fix. You can't tell from the outside whether they have. Here's how to find out in two minutes.

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

If your website runs on WordPress, or anything else built on PHP, a stranger with no password may be able to take over its server right now with one request. They'd get the site, everything your clients have typed into its forms, and a domain with your name on it to send phishing from. PHP fixed the two bugs that allow it, CVE-2026-109618 and CVE-2026-109619, on 21 October 2026, and rated each 9.2 out of 10, critical.[2][3] Your site stays open until your host installs 8.5.12, 8.4.27, 8.3.36 or 8.2.35. To see whether yours has, type its address into this free check.

PHP's own advisory is headed "Critical remote code execution vulnerabilities, update now",[1] and CERT-EU, the European Union's cyber emergency team, reports proofs of concept already circulating.[4] On the riskiest setup the attack lands before any of your site's own code runs, so no WordPress security plugin gets the chance to stop it.[1]

PHP runs 6 in 10 Canadian websites, by W3Techs' count of .ca sites,[8] and about 7 in 10 worldwide.[7] Later that day I read 3,114 Canadian law-firm websites: 6 in 10 run PHP, and of the 534 that show their version, 484 (9 in 10) were on one PHP hasn't fixed.

WordPress alone runs about 4 in 10 of all websites, and every one of them runs on PHP.[9] Squarespace and Wix don't run your site on PHP you control, so on those there's nothing for you to update.

A version with extra text after the number is a Linux distribution's own build, and distributions patch the old number instead of moving to the new one. Ubuntu's 8.3.6-0ubuntu0.24.04.13 and 8.1.2-1ubuntu2.28 both carry the fix.[5] For those, ask your host.

Check your site in two minutes

The fastest way: type your site's address into the PHP check. It reads the version your site reports and tells you whether it's patched, below the fix, or a question for your host. If your site hides its version, which most do, use one of these instead.

Three places show your PHP version: WordPress's admin, your hosting panel, and sometimes a response header anyone can read. A plain number at or above the fix in the table is patched. Anything else is a question for your host.

On WordPress, log in as an administrator and go to Tools > Site Health > Info, then open Server. The line PHP version is the one you want.

On cPanel hosting, open MultiPHP Manager. It lists the PHP version each of your domains uses.

From outside, in a terminal (on Windows, type curl.exe instead of curl):

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

Look for a line starting x-powered-by: PHP/. In my scan below, 5 of 6 PHP sites left it out. Hiding it is good practice and proves nothing either way.

What the number means:

1. A plain number at or above the fix for its branch, such as 8.2.35. These two bugs are patched on that server.
2. A plain number below the fix, such as 8.2.34, or 8.1 and below unless your host confirms a patched package. Treat it as exposed and send your host the message below today.
3. A number with extra text after it, such as 8.3.6-0ubuntu0.24.04.13. A distribution's build, which may carry the fix. Ask your host.

Not sure your site is WordPress? View the page source (Ctrl+U, or Cmd+Option+U on a Mac) and search for wp-content. If it's there, the site runs on PHP.

What to send your host

On shared and managed hosting, your host decides when PHP gets updated, so the fix is a message to them. This one asks for the three facts that settle whether you're exposed: the version, whether it carries the fix, and how PHP runs on your server. Copy it, put in your domain, and send it to their support.

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?

The third question matters because the risk differs. The full attack was shown working against Apache mod_php with PHP's default limits, and PHP calls that setup the highest risk.[2] On PHP-FPM and LiteSpeed, attacks through a particular application are likely but not yet demonstrated.[2] Every setup that serves web pages is at risk.[1]

If your host offers settings changes instead of an update, such as memory_limit=-1 or turning off session upload progress, those close some of the known paths. PHP's own words: they "do not make an installation safe".[1] Ask for a date for the update anyway.

Where some common hosting setups stood on 21 October, from the Dutch NCSC's tracking list:[5]

A host on a fixed panel still has to install the update, so send the message either way.

What I found on 13 Victoria law firm sites

On 21 October at 12:43 PDT, about six hours after the fix shipped, I sent one header request to each of 13 law firm websites in and around Victoria, BC. At least 6 of the 13 run on PHP. 5 of those 6 hide their version, so nobody outside can tell whether they're patched. The sixth announces PHP/8.2.34 on LiteSpeed: one release below the fix.

OpenStreetMap lists 17 law offices with a website within 20 km of Victoria; the 13 leave out plainly large firms, a chosen sample, not a random one.[6] Each got one request for its home page's headers. I tried no exploit. The same site showed PHP/8.2.34 at 12:31 and again at 12:43. I'm not naming the firm.

13 sites is small, so 1 in 13 isn't a rate for the province. It does show the gap: nobody outside can tell which of the five hidden WordPress sites are patched. Only the host's reply settles it. Later the same day I read 3,114 Canadian law-firm websites the same way: 72% of those on PHP hid the version, and 484 of the 534 that showed one were below the fix or on 8.1 or older. The BC numbers, and what they mean under the Law Society's rules, are on the law firm page.

Why one more patch won't be the last

Both bugs are memory-safety bugs in the C code at the core of PHP.[4] CVE-2026-109618 frees memory that was never set up, when a request runs out of memory partway through reading an upload. CVE-2026-109619 keeps pointing at one request's memory after it's freed, and the next request on the same worker uses it.[3] Updating fixes these two.

The obvious fix is to update and move on, and you should. It works until the next advisory. This class of bug is common: around 70% of Chromium's serious security bugs are memory-safety problems.[11] Finding them is getting cheap. Anthropic's red team reports Claude found and validated more than 500 high-severity vulnerabilities in open-source code,[12] and XBOW, an AI tester, reached the top of HackerOne's US leaderboard.[13] My reading: the next PHP advisory comes sooner, for attackers and defenders alike.

The fix that lasts is a site that doesn't run that kind of code when someone visits. This page is static files, built ahead of time by a compiler I wrote in Rust and served as they are, with no PHP and no database answering your request. Where a site does need code that runs on each visit, I write it in Rust. In safe Rust, code that reads memory after freeing it, or before setting it up, doesn't compile, so that class of bug never reaches a live server. When Android wrote new code in memory-safe languages, memory-safety bugs fell from 76% of its vulnerabilities in 2019 to 24% in 2024.[14] The Canadian Centre for Cyber Security co-signed the 2023 call for software makers to plan that move.[15]

I read CERT-EU's advisory the morning it came out, checked it against PHP's own advisories, and measured real sites the same day.

Common questions

Is WordPress affected? WordPress itself isn't the bug; the PHP underneath it is. Every WordPress site runs on PHP, so every one is exposed until the PHP on its server is updated. Updating WordPress or its plugins doesn't change the PHP version.

Are Squarespace, Wix and Shopify sites affected? Those platforms run and patch their own servers, and none of them runs your site on PHP you manage. There's nothing for you to update.

Does my host patch PHP for me? On managed WordPress and most shared hosting, yes, but on its own schedule. The Linux distributions got the patches in advance.[1] Ask for the version and a date.

My host says 8.3.6 and swears it's patched. Is that possible? Yes, on a distribution's build (see the note under the version table). Ask for the full version string, with the part after the dash.

What about PHP 8.1 and older? The PHP project no longer releases fixes for them, and 36% of WordPress sites that report to WordPress.org run one.[10] It published source patches for 7.4, 8.0 and 8.1, and some vendors ship patched packages.[1] If your host can't confirm either, the site needs a supported PHP version.

Does this affect things that aren't websites? Yes. PHP is built into appliances, network devices and admin panels. The Dutch NCSC keeps a list of affected products.[5]

If you'd rather not do this again at the next advisory, a site with no PHP has nothing to patch, and that's what I build. If you look after a firm's website and want a second read of your host's reply, or to talk about that, write to me: mackenzie@mackenziebowes.com or @_mackenziebowes. I'm measuring other professions' sites in BC the same way, and each one is linked from here. First: what these bugs mean for a BC law firm's website, including what Law Society Rule 10-4 asks of you.

This page changes as the advisories do. 21 October 2026: first version, from CERT-EU 2026-018 v1.1, php.net and both GitHub advisories read at 12:40 PDT and the scan at 12:43 PDT; later the same day, usage figures and the memory-safety record.