Updating WordPress doesn't update PHP. Who patches it?

Last week, government sites, council pages and corporate websites across Europe went into maintenance mode. The reason was two critical flaws in PHP, the language that runs WordPress and much of the web, fixed on 21 October 2026. The PHP project called them "critical remote code execution vulnerabilities" and told every user to update immediately. The detail that caught most companies off guard is simple: updating WordPress doesn't update PHP. Someone else has to do it, and in a lot of organizations nobody is sure who.

Your product may not run on PHP at all. Your marketing site, your blog, your landing pages or the agency that built them very likely do. That's where this one lands.

What happened

The facts from the primary sources, without the noise:

• The fix. PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October. Both flaws are rated 9.2 out of 10 and, per PHP, "can allow unauthenticated remote code execution", meaning an attacker could take over the server without logging in.
• Who is exposed. PHP says the risk covers "all PHP installations serving web requests", across the common ways of running it.
• Old versions get no official fix. In PHP's words: "PHP 8.1 and older no longer receive updates from the PHP project." Some Linux distributions and long-term support vendors ship their own patches.
• What the authorities said. CERT-EU, the EU institutions' security team, recommends updating "as soon as possible" and, where that isn't feasible, "isolating internet-facing resources from public networks until the fix is applied and verified." In plain terms: take the site offline.
• Attacks. watchTowr reported exploitation attempts from 21 October, and Cloudflare's CTO reported "early attacks emerging." On 26 October, BleepingComputer reported the first confirmed successful exploitation, recorded on honeypots (decoy servers) running PHP 8.4.26, with the findings confirmed by Expel researcher Marcus Hutchins. As of that report, no real organization had been publicly confirmed as compromised.
• A third issue, still without a fix. On 23 October PHP disclosed CVE-2026-115560, which it calls an "unlikely RCE vector" that needs an unusual configuration. It will be fixed in the next regular release, with no date yet. Until then PHP recommends a configuration change, and for the two main flaws it repeats that "updating is the only safe choice."
• It's not only websites. PHP also runs inside products you may never think of as PHP. Help Net Security reports that Palo Alto Networks confirmed its PAN-OS firewalls and Panorama are affected, with fixes rolling out through 30 October, and that Cisco lists Expressway, Duo Access Gateway and a wireless backhaul product, one of them with a fix not expected until February 2027. Fortinet was still investigating four products.

Malwarebytes put the business consequence in one line: "Updating WordPress or its plugins is not the same as updating PHP. Hosting providers or server administrators may need to apply the fix."

The mechanism: three layers, three owners

A typical company website has three layers, and they're often owned by three different parties.

1. The application. WordPress, its theme and its plugins. The marketing team or an agency updates these, often from a dashboard with an "update" button.
2. The runtime. PHP itself, the program that executes WordPress on the server. It doesn't appear in the WordPress dashboard and doesn't update when WordPress does.
3. The server. The machine and its operating system, usually run by a hosting company, sometimes by an IT contractor, occasionally by nobody in particular.

These flaws live in layer 2. The people who usually click "update" sit in layer 1, so for them the site looks up to date while it's exposed. The fix has to come from layer 3, and whether it does depends on a contract nobody has read in a while.

A few details make this harder than it sounds:

• The version number can lie. Hosts that apply backported patches may leave the visible version unchanged. A site can say "PHP 8.4.26" and be protected, or say the same and not be. You have to ask.
• The patched version may itself be near its end. PHP's own announcement notes that PHP 8.2 "reaches end of life on 31 December 2026." A site patched to 8.2.35 now will be back on an unsupported version in about ten weeks.
• Firewall rules are a stopgap. Security vendors deployed rules to block known attack patterns, and Cloudflare's CTO warned that firewall mitigations "are only a stopgap." They help only if the server can't be reached directly, and only until attackers adapt.

Why this is a business decision, not a technical one

Taking a website offline is a tradeoff that marketing, sales and leadership feel, not just engineering. A day without the site costs leads and looks bad. A compromised server can cost far more: customer data, a defaced homepage, malware served to visitors, or a foothold into other systems.

Most companies made that decision under pressure last week, often without knowing who could even make the fix. That's the same pattern we wrote about when one Google Cloud zone went down and took banks with it: the risk wasn't in the part anyone was watching. It was in a dependency that had been delegated and then forgotten.

What to do now

• Ask your host in writing whether the patched PHP build is the one actually serving each of your sites, not scheduled, installed. Malwarebytes gives the same advice: confirm fixes are "installed, not just scheduled."
• List every PHP site you have, including the ones you forgot: old campaign pages, a careers site, a help center, the blog an agency set up years ago. Each one needs a named owner for the runtime, not just for the content.
• Get off PHP 8.1 and older. These no longer receive fixes from the PHP project. If moving isn't possible this week, pay for a vendor that backports patches, or take the site offline.
• Plan the move off PHP 8.2 now. Its end of life is 31 December 2026, so a site upgraded only as far as 8.2 needs another upgrade before the year ends.
• Decide in advance who can take a site offline, and how a holding page goes up. The worst time to work that out is the morning an advisory lands.
• Ask your network and security vendors too. Firewalls, VPN gateways and appliances can embed PHP. Ask each vendor whether its products are affected and when the fix ships, and track the ones still "under investigation."
• Watch for the next PHP release. The third issue will only be fixed in the next regular release. Apply PHP's recommended configuration change until then, and make sure someone is watching for that release.
• Put the runtime in the contract. If an agency or host manages your sites, the agreement should say who applies security updates to PHP and the server, and how fast.

Mapping who owns which layer, before something breaks, is a big part of how we take products to production. It's unglamorous, and it's what decides whether a week like the last one costs you an afternoon or a breach.

Key takeaways

• PHP fixed two critical flaws on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Websites across Europe went offline while they were patched.
• PHP 8.1 and older get no official fix, and PHP 8.2 reaches end of life on 31 December 2026.
• Updating WordPress or its plugins does not update PHP. The host or server administrator has to apply the fix.
• Successful exploitation was confirmed on decoy servers on 26 October. No real organization had been publicly confirmed as compromised.
• A third, lower-risk issue has no fix yet, and PHP also runs inside firewalls and other appliances from vendors such as Palo Alto Networks and Cisco.
• Ask your host in writing, inventory every PHP site, name an owner for the runtime, and decide in advance who can take a site offline.

FAQ

What is PHP2Shell? The name given to two critical vulnerabilities in PHP, fixed on 21 October 2026, that could let an attacker run code on a web server without logging in. PHP rates both 9.2 out of 10.

My website runs on WordPress. Am I affected? Possibly. WordPress runs on PHP, so the fix depends on the PHP version your host runs, not on WordPress. Updating WordPress or its plugins does not apply this fix. Ask your host to confirm the patched PHP is installed.

Should I take my site offline? If your host confirms the fix or temporary protections are in place, usually not. If you run your own server and can't patch or protect it yet, CERT-EU recommends isolating it from the internet until the fix is applied and verified.

Is my site hacked if it was offline last week? Not necessarily. Many sites went into maintenance mode as a precaution while patches were applied. As Malwarebytes notes, temporary downtime alone doesn't mean a site was breached.

I don't run any PHP sites. Can I ignore this? Not yet. PHP runs inside some firewalls, gateways and other appliances. Palo Alto Networks and Cisco have confirmed affected products. Ask your vendors whether you're exposed and when their fixes ship.

What if I'm on PHP 8.1 or older? The PHP project no longer fixes those versions. Upgrade to a supported version, or use a vendor that provides backported patches. If neither is possible soon, keeping the site offline is the safer choice.