Earlier today the PHP project shipped an emergency security release. If you run a website, that sentence probably means nothing to you — so let me translate it.
A huge chunk of the internet runs on a programming language called PHP. WordPress runs on it. WooCommerce runs on it. So do Magento, Drupal, Joomla, and a long list of the tools small businesses quietly depend on. This morning, security researchers confirmed that two flaws in PHP itself let an attacker take over a server without logging in, without a password, and before any of your website's own code gets a chance to run.
The researchers who built the proof-of-concept nicknamed it PHP2Shell. The two official bug IDs are CVE-2026-109618 and CVE-2026-109619, and both carry a severity score of 9.2 out of 10. That is about as bad as these ratings go.
Here's what that actually means for you, who's exposed, and the short list of things worth doing today.
What happened, without the jargon
On October 20, details of two unpatched PHP vulnerabilities leaked ahead of schedule. The security firm watchTowr confirmed they could be used for remote code execution — meaning an attacker can run their own commands on your server. The PHP team had been quietly preparing a fix and was forced to move fast. They released the patched versions today, October 21, at around 14:00 UTC (CERT-EU, Sansec).
By then it was already too late to be calm about it. Cloudflare reported seeing attacks against these bugs at 07:43 UTC — hours before the official fix even shipped (Sansec). Working exploit code is now public. When a reliable, no-login exploit for something this widespread goes public, mass scanning and automated attacks follow within hours, not weeks.
To give you a sense of how seriously people took it: several major Dutch organizations pulled their sites offline today as a precaution, including the tech-news site Tweakers, the Dutch House of Representatives, and the country's national cyber security center, the NCSC (Sansec). A PHP core developer publicly said that taking servers offline was the most sensible option until the patch landed.
Why this one is worse than the usual "update available" notice
Most security bugs you can shrug off. This one has three properties that make it genuinely nasty.
It runs before your website does. Normally, a hacker has to find a weak spot in your site — a sloppy plugin, a reused password, an outdated theme. PHP2Shell skips all of that. PHP reads and parses an incoming web request before it hands control to WordPress, WooCommerce, or whatever you've built. The attack happens in that gap. So "my site is well-built" and "my plugins are up to date" don't protect you here. The weakness is one floor below your site, in the engine the whole thing sits on.
It needs no login. Both bugs are what's called unauthenticated remote code execution. The attacker doesn't need an account, a stolen password, or any foothold. A single malformed web request can be enough (CERT-EU).
One of the two bugs also leaks your secrets, Heartbleed-style. According to Sansec's analysis, CVE-2026-109618 can hand an attacker chunks of your server's memory — and that memory can contain other people's passwords, active session tokens, API keys, even your site's TLS private keys. It can do this even on sites that never ask anyone to log in, because the leaky code path runs before your application starts (Sansec). If you remember Heartbleed back in 2014, it's that flavor of problem.
And the kicker: the vulnerable code has been sitting in PHP since version 5.4.0, released in 2012. This has been exploitable, in theory, for thirteen years. Default configurations are affected (Sansec).
The quick technical version (for the curious)
You can skip this section — but if you want to know what's actually broken:
- CVE-2026-109618 (CVSS 9.2) is a memory-corruption flaw tied to how PHP handles running out of memory. PHP enforces a memory limit by abruptly aborting a request that goes over it. That abort can interrupt PHP in the middle of setting up internal data — for example, while it's parsing an uploaded file. Afterward, the cleanup routine treats half-initialized, attacker-influenced data as if it were valid, and frees memory it shouldn't. That's the opening (CERT-EU). Sansec ties the same bug to PHP's "upload progress" feature and the memory-leak behavior described above.
- CVE-2026-109619 (CVSS 9.2) is a "stale state" flaw. PHP reuses worker processes to serve many requests. Internal state from one request can survive after its memory has been freed — say, after a fatal error — and a later request handled by the same worker can then use that freed, stale data before it gets reset (CERT-EU). Researchers also tie it to a fatal-error backtrace path and an OPcache type-confusion issue (Sansec).
The exploit tool chains both bugs into a single no-login attack (Sansec). Researchers have demonstrated working remote code execution against current versions of Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony, and WHMCS (Sansec). In other words: if it's a popular PHP app, assume it's on the list.
"Okay — is my website affected?"
Here's the honest, practical breakdown.
If your site runs WordPress, WooCommerce, Magento, Drupal, Joomla, or any custom PHP app — yes, your server is affected until PHP is updated on it. It doesn't matter how clean your own code is. The flaw is in PHP, the layer underneath.
If you're on shared or managed hosting (most small-business WordPress sites are), the fix is something your host applies to the server, not something you do inside your dashboard. Many reputable hosts received the patches early, under embargo, and some have already rolled them out. Some haven't. You need to confirm, not assume.
If your site is a modern static or "headless" build — the kind we increasingly move clients to, where the front end is pre-built and served from a content delivery network, with no PHP running on the public server — then this specific attack has far less to grab onto. There's no PHP engine sitting in front of your pages to exploit. (That's not a magic shield for every situation, but it genuinely removes this entire class of problem from your public front door. More on that below, because it's the real lesson here.)
If you're not sure what your site runs — that's exactly the kind of thing we check for clients. If you work with us, we already know, and we're already on it.
What to do right now
1. Get PHP updated on your server. This is the only real fix. There is no plugin, no theme setting, and no "security plugin" that patches it from inside your site — the problem lives below all of that (Sansec). The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 (CERT-EU). If you manage your own server, update now. If you don't, contact your host today and ask them, in plain words: "Have you patched for CVE-2026-109618 and CVE-2026-109619 yet?" A good host will have a straight answer.
2. If you're stuck on an old PHP version, this is your wake-up call. PHP only officially supports 8.2 and newer. If you're on 8.1 or older, you get no official fix — you're relying on your host or Linux vendor to back-port it, and some won't (Sansec). The PHP team did publish minimal emergency back-ports for 7.4, 8.0, and 8.1 for people who build from source, given how severe this is (CERT-EU). But "my site is three PHP versions behind" is a problem that long predates today.
3. If you genuinely can't patch within the hour, there are stopgaps — but know they're partial. Security researchers published temporary mitigations that reduce exposure without closing the hole completely (CERT-EU, Sansec). The most effective is taking the site offline or making it read-only until it's patched — note that WordPress/Magento "maintenance mode" does not help here, because PHP parses the request before your app ever checks that flag (Sansec). Blocking multipart/form-data requests at the web-server level shuts a known trigger but breaks file uploads and some checkouts. These are "buy yourself a few hours" moves, not fixes. Patch as soon as you can.
4. After you patch, rotate your secrets. Because CVE-2026-109618 can leak memory, treat passwords, API keys, and session secrets on any exposed server as potentially compromised. Once you're on a fixed version, change them. Better a boring afternoon of rotating keys than a quiet breach you never noticed.
The uncomfortable question nobody wants to ask
Here's the part I care about most, and it's the part most "update now" articles skip.
Why was your small-business website — your dentist's office, your law firm, your med spa, your e-commerce store — exposed to a thirteen-year-old flaw in a language you've never heard of, in the first place?
Because for fifteen years, "build a website" has quietly meant "run a WordPress install on a server that's always on, always exposed, and always one neglected update away from trouble." That setup made sense in 2010. It makes a lot less sense now. Every plugin is a door. Every PHP version is a maintenance obligation. And days like today are the bill coming due — not because you did anything wrong, but because the whole architecture assumes someone, somewhere, is patching a server on your behalf at 3 a.m.
The sites we build now don't work that way. We pre-build the pages and serve them from a global content network, with the dynamic pieces handled by locked-down, managed services. There's no PHP engine sitting on the public internet waiting to be exploited. When a day like today happens, those sites mostly just… keep running. That isn't luck. It's the architecture doing its job. We're not the only ones who noticed — this is exactly why so much of the modern web has moved this direction.
That doesn't mean WordPress is evil or that everyone should rip theirs out tomorrow. Plenty of businesses have real reasons to stay on it, and when they do, the answer is disciplined patching, good hosting, and someone whose actual job is to watch for mornings like this one. What it does mean: if a single disclosed bug can knock a national parliament's website offline, the question "what is my site actually built on, and who's responsible for keeping it safe?" deserves a real answer — not a shrug.
What we're doing for our clients
For the sites we manage, we've already been through our list. We know which stacks each client runs, which ones touch PHP, and where the patches stand. The static builds are a non-event. The WordPress and WooCommerce properties are the priority, and we're confirming PHP versions and host patch status directly rather than taking "should be fine" for an answer.
If you're a client and you haven't heard from us about your specific site, it's because yours wasn't exposed to this one. If you want that confirmed in writing anyway, just ask — we'd rather you have the peace of mind.
If you're not a client and you're reading this wondering whether your site is quietly sitting on an unpatched server right now: that's a free thing we'll check for you. No pitch, no obligation. You'll either sleep better tonight or you'll be very glad you asked.
Sources
- PHP project security release, October 20–21, 2026 — php.net
- CERT-EU Security Advisory 2026-018, Critical Vulnerabilities in PHP — cert.europa.eu
- Sansec Threat Research, PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619) — sansec.io
- Wiz Research, PHP2Shell writeup — wiz.io
- Calif, PHP2Shell technical writeup — calif.io
- GitHub Security Advisories: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp
- NCSC-NL affected-software list — github.com/NCSC-NL/php2shell
This article is for general guidance and reflects what was publicly known on October 21, 2026. For advice specific to your site, patch your PHP and confirm with your host — or reach out and we'll take a look.
