This week, some organizations took their own websites offline on purpose. Not because they'd been hacked, but because of a flaw in PHP, the software behind about 70% of websites. If you have a website, there's a fair chance it runs on PHP too. The good news: the fix already exists. By the end of this article you'll know the one question that tells you whether your site has it.
What happened
On October 21, 2026, the PHP project released emergency updates for two critical flaws, CVE-2026-109618 and CVE-2026-109619, which security researchers have nicknamed PHP2Shell. Details had leaked a day early, and attacks started before many sites could update. Government cyber agencies in Europe, the UK and the US urged everyone running PHP to update immediately, and some organizations, including Dutch government login services, took sites offline as a precaution until they could.
First, what PHP actually is
Think of your website as a restaurant. The pages your customers see are the front counter. PHP is the kitchen behind it: you never see it, but every form, login, booking and checkout goes through it. WordPress runs on PHP, and so do Drupal, Joomla and a large share of custom business sites. When the flaw is in the kitchen, it doesn't matter how nice the counter is.
The two flaws, spelled out
Flaw one: the half-written ticket. An attacker sends a request built to make PHP run out of memory partway through setting it up. PHP stops halfway, and when it cleans up afterwards, it treats the half-finished data as if it were complete. Imagine a waiter interrupted mid-order, and the kitchen cooking from the half-written ticket anyway. That confused state is the attacker's way in.
Flaw two: the room nobody cleaned. After one visitor's request finishes, some of its leftovers aren't properly cleared, and the next request handled by the same part of the server can pick them up. It's like a hotel room that wasn't cleaned, so the next guest finds the last guest's keys. Those leftovers can include passwords, logins to other services and payment keys.
Together, they let a stranger run their own commands on your server, with no password and no login, from a single crafted request. Researchers showed it working against the latest WordPress, Drupal and Joomla, and even against a one-line "Hello World" page. So this isn't a bad plugin or a weak password. It's the engine itself, which is why every PHP version back to 5.4 has at least one of the two flaws.
Why it moved so fast
The vulnerable code had been sitting in PHP for about 14 years. It was found this summer by security researchers using AI tools, and the same kind of tools help attackers turn a flaw like this into a working attack quickly. Cloudflare reported tens of thousands of attempts within 45 minutes of the news getting out, and millions by that evening. Palo Alto Networks counted about 22.6 million potentially vulnerable PHP installations. This isn't something to put on next month's list.
The one question to ask about your website
Ask whoever hosts or manages your site:
"What PHP version are we on, and was it updated after October 21?"
Here's how to read the answer:
- 8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer: you have the fix.
- An older 8.2, 8.3, 8.4 or 8.5 release: it needs updating today.
- 8.1 or older: the PHP project no longer updates these. Some hosts ship their own patched versions, so ask whether they've applied the fix for these two CVEs. If not, upgrading PHP is the real fix, and plan for it anyway: PHP 8.2 reaches end of life on December 31, 2026.
- "We don't run PHP": then this one doesn't apply to you. A static website, made of finished pages with no PHP on the server, has nothing here to attack.
- "I'm not sure": that's the answer worth fixing, whatever the version turns out to be.
If it can't be updated today
Put the site into maintenance mode until it can be. A few hours offline is a much smaller problem than a server someone else controls. The PHP project lists some settings that reduce the risk in the meantime, but it's clear that updating is the only complete fix, so treat them as a stopgap, not a substitute.
If your site ran an unpatched version at any point from October 17 on, assume it may have been looked at, even if it was taken offline before the announcement: Amazon's threat team saw the first attempts on October 17, days before the fix was public. After updating, change the passwords and keys stored on that server (the database, email, payment and API keys), and ask whoever manages it to check for warning signs like repeated server errors or unexplained restarts. There's no simple test that proves a server wasn't touched, so changing those keys is the sensible default.
Whose job is this, actually?
For most small businesses the honest answer to "who updates PHP on our server?" is "I'm not sure." Some hosts update it automatically; many older hosting plans leave sites on the same version for years. A security plugin won't help here either: the attack can happen before WordPress, or any plugin, even starts.
The business websites we build are static: finished pages served from Cloudflare's network, with no PHP, database or admin login on the public site, which is why this one doesn't reach them. That's a choice we explain on our website security page. But plenty of good businesses run WordPress or another PHP site, and it can be kept perfectly safe, as long as someone's job is to keep it updated. If you'd like a straight answer on what your site runs and whether it's patched, we're happy to check it with you, even if the answer is "you're fine."
You don't need to follow every security headline. You just need to know who's watching for the ones that matter, and this week, the question is one sentence long.
