The Day 70% of the Web Was Left With an Unlocked Back Door

If your website was built with PHP, there’s a good chance you should check on it as soon as possible. On October 21, 2026, the team behind PHP released emergency updates for two serious security flaws, tracked as CVE-2026-109618 and CVE-2026-109619.

First, What Is PHP?

PHP is a programming language that runs behind the scenes on a web server. When you visit a page that shows your latest orders, a blog post, or a contact form, PHP is often the thing that puts the page together before it reaches your screen.

A good way to picture it: your website is a restaurant. The pages you see are the dining room, and PHP is the kitchen. Visitors never see it, but it takes each order, gathers the ingredients and sends out the finished dish.

PHP has been around for decades. According to the web survey site W3Techs, it’s used by 69.3% of the websites whose server-side language is known, which is roughly 70% of the web. It also powers popular platforms like WordPress. That’s why a flaw in PHP itself matters so much. It isn’t one app or one plugin. It’s the kitchen that thousands of different sites share. If you’ve ever had someone “build you a WordPress site,” you’ve almost certainly got PHP running somewhere, even if nobody ever mentioned it.

Why This One Is A Big Deal

The PHP project’s own security advisories rate both bugs 9.2 out of 10 for severity. That puts them in the “critical” bucket, and for good reasons. An attacker doesn’t need a password or an account, and doesn’t need you to click anything. They just need to send a specially crafted request to your website over the internet. If it works, they can run their own code on the server.

The timing is part of why this has people on edge. Many in the dev community and social media are calling this “Black October”, a nickname for a rough few weeks of security news this month. Besides these two PHP flaws, it lumps in a reported bank data leak, a compromised certificate authority and a tampered software release. It’s an informal label rather than an official one, and the post doesn’t say who came up with it.

What's Actually Going Wrong

The two bugs are different, but they’re cousins. Both come down to PHP getting its housekeeping wrong when something unexpected happens partway through handling a visitor’s request.

Imagine a busy coat check. Normally, when you hand in your ticket, the attendant clears the hook and sweeps the slot clean before the next person steps up. Now imagine someone causes a scene at the counter, and the attendant rushes off without clearing the hook. The next person gets handed a ticket that points at something that’s no longer there. A clever troublemaker could arrange for that spot to contain whatever they like.

CVE-2026-109618 is the “out-of-memory” bug. If PHP runs out of memory while it’s reading an incoming request (the advisory describes oversized or oddly built file uploads as one way to push it there), it bails out in a messy way and leaves its internal notes in a broken state. PHP then trips over those notes while cleaning up, and that can let an attacker take over.

CVE-2026-109619 is the “reuse-stale-state” bug. PHP keeps some information around between visitors, and sometimes a request ends in a crash or error before that information gets cleared. The next request handled by the same worker can then use stale information that points to memory that’s already been given up. One feature, called session upload progress, is turned on by default and is involved in one of the confirmed attack routes.

In plain terms, no one needs to know a password. A stranger could just send some unusual web traffic and potentially end up running code on your server.

Could My Website Be Affected?

If your site runs on PHP, probably yes, unless it’s already been updated. Platforms like WordPress are built on PHP, so a lot of everyday business sites count. Not sure what yours uses? Your web developer or hosting provider can tell you in a minute.

The number to look for is your PHP version. These are the patched releases, all published October 21, 2026:

PHP 8.5: fixed in 8.5.12
PHP 8.4: fixed in 8.4.27
PHP 8.3: fixed in 8.3.36
PHP 8.2: fixed in 8.2.35

Anything older than those numbers within the same family is affected. PHP 8.1 and older is a tougher spot: those versions no longer get security fixes, so there’s no patch coming. The only real answer there is moving to a newer version.

You can usually see your PHP version in your hosting control panel, or just ask your host.

What You Can Do About It

The good news is that the fix is an update, and it’s usually a quick one. Here’s a sensible order to work through:

1. Ask Your Host Or Developer Where Things Stand

Many managed hosts are already rolling out the patched versions. A simple “are we on a fixed PHP release yet?” gets you a clear answer.

2. Get On A Patched Version

That means 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or newer). If your host handles updates, this may be a single click or already done. If you’re on PHP 8.1 or older, it’s worth planning a move to a supported version.

3. Check For Anything That Doesn't Belong

If your site was running an affected version, take a look at folders where people can upload files, such as an uploads folder. PHP files you don’t recognize are a red flag. If you find some, remove them and change the passwords and keys your site uses, like database passwords and API keys.

4. If You Can't Update Right Away, Ask About The StopGap Settings

Your developer can switch off PHP’s session upload progress feature, remove the memory limit, and (on PHP 8.5) turn off detailed crash reports. These make attacks harder, but the PHP team is clear that they don’t fully fix the problem. The memory setting also has a trade-off: one busy request can use all of the server’s memory, so treat it as a short-term patch.

If all of that sounds like a lot, step 1 is the most useful one. A short message to your host is often enough to find out whether you’re covered.

How Saskatoon's Varial Hosting Handled It

It helps to see what a fix looks like from the host’s side. Varial Hosting published an account of its response, and it took a different route from the usual “update PHP” advice.

According to Varial, early details of the vulnerabilities leaked ahead of schedule on October 20, and a proof-of-concept attack tool appeared soon after. Varial took its website and client portal offline behind a maintenance page to protect customer data, then brought them back by the time it posted its update on October 21.

Here’s what they say they did:

Tightened PHP settings across its servers. These are protective configuration changes applied by Varial, so customers don’t have to touch anything.

Updated its web application firewall. The firewall sits in front of customer sites and was given new rules to block the attack patterns and the scanning activity that tends to follow a leak like this.

Patched PHP in place. Rather than moving everyone to a newer PHP version, Varial had its security partner apply the security fixes directly to the PHP versions already running on its servers. Varial says this avoids the compatibility headaches that a version jump can cause for plugins.

Varial says every PHP version it offers is covered, from PHP 5.2 through 8.5, and that customers don’t need to do anything. It also reports that it hasn’t detected any security breaches on its network. Those are Varial’s own statements, and its post doesn’t name the security partner or say how long it will keep patching the oldest versions.

The takeaway for site owners: a good host may handle this for you without you lifting a finger, but it’s still worth asking yours what they did and when. If you are looking for hosting provider, we have nothing but great things to say about Varial.

The TLDR Version

Two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, could let someone run their own code on a web server without logging in. Both come from PHP mishandling its internal state when a request goes wrong. The PHP team fixed them on October 21, 2026, in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and updating is the only complete fix.

For most site owners, the practical steps are small: find out whether your site uses PHP, ask your host or developer if you’re on a patched version, and glance through your upload folders for files that don’t belong. Some hosts, like Varial Hosting, are protecting customers on their end with server-side patches and firewall rules, so it’s worth asking yours what they’ve done. If you’re running PHP 8.1 or older, this is a good prompt to plan an upgrade.