Patch It or Unplug It: PHP2Shell and the Web Interfaces Hiding in Your OT Network

Mira, I’ve been doing this a while, and it’s not often the official advice on a bug boils down to this: if you can’t fix it, pull the plug.

That’s where we are with PHP2Shell.

Governments, including the US and Germany, are saying it out loud. In the US, CISA said organizations that can’t update right away, or that still run PHP 8.1 or earlier, “should take PHP-based systems offline until they can be patched or updated.” Germany’s BSI went further. It recommends considering a temporary disconnection from the internet, because none of the workarounds give complete protection. BSI even noted that some operators had already pulled PHP servers off the internet as a precaution.

The UK NCSC, Canada and CERT-EU said a softer version: if you can’t patch or mitigate, consider taking the system offline or isolating it from public networks.

Honestly? It’s the ultimate air gap. Very “have you tried turning it off and on again,” except please skip the “on again” part until you’ve patched. We laugh, but when the safest thing to do with a box is unplug it, that tells you how serious this is.

What actually happened

Two critical flaws in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619, went public on October 21. Not a WordPress plugin. Not some framework. The runtime underneath all of it.

php.net says they “can allow unauthenticated remote code execution.” In plain words, someone who never logs in can get code running on your server as the web worker account.

PHP, which assigned the CVEs, rates both at 9.2 on CVSS v4.0.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

And here’s the ugly part. PHP 8.1 and older get no official fixed release. php.net’s security team only provided minimal source backports for 7.4, 8.0 and 8.1. If your box runs an old branch and you can’t rebuild PHP yourself, you’re waiting on someone else.

Not every PHP box is equal

Per php.net, the risk is highest with Apache mod_php, where a demonstrated exploit fires “before any application code runs.” So no, your perfectly written app doesn’t save you.

PHP-FPM is harder to exploit, but it’s still in scope. The PHP Foundation says code execution was also confirmed on FPM through application paths. Scripts that only run from the command line and never serve web requests fall outside php.net’s stated scope. Just check before you assume a box is CLI only.

The php.net config tweaks are a stopgap, not a fix. Their words: “only an update is a complete solution.”

Is it being exploited?

Here’s the honest version, amigos.

Amazon saw an exploitation attempt against its honeypots on October 17, four days before disclosure, and more from multiple actors after. watchTowr saw exploitation in its honeypot network from October 21. But AWS itself says “it’s unclear if any of these attempts would have succeeded in real-world systems.”

Sophos first said it saw successful exploitation, then corrected that to scanning and a small number of failed attempts, with “no evidence of a successful compromise.”

So that’s attempts, yes. I haven’t seen a confirmed real-world compromise documented. And as of my check on October 23, it’s not in CISA’s KEV catalog. That can change fast, so check again.

No attribution either. AWS says “multiple actors” and nothing more.

Why OT folks should care

PHP isn’t just websites. It’s baked into the web interfaces of products you don’t patch yourself. CISA said it straight: PHP “is often a component of other software and prevalence may not be directly observable.”

Think of it like the wiring behind the drywall. You never see it, but if it’s bad, the whole house has a problem.

OT and building vendors are already talking:

Delta Controls has a patch for enteliWEB, its building management front end. Until you patch, keep it off the public internet and use a VPN. For its IP controllers the firmware fix is still pending, so the mitigation is to disable the embedded HTTPS web server, block inbound 443 and keep the controllers on trusted networks. Delta says it’s “not aware of any confirmed exploitation affecting Delta products.”
Schneider Electric lists EcoStruxure Security Expert (fixed in 1.48.4.0), ProLeiT LINEoptimize (remediation through ProLeiT support) and EcoStruxure Control Engineering (remediation plan in progress, apply mitigations).
Johnson Controls posted a PHP2Shell notice with general guidance.
Cisco says Ultra-Reliable Wireless Backhaul is vulnerable, with a fix estimated for February 2027. Exploiting it needs an authenticated admin, which is why Cisco scores it lower. Its Unified Industrial Wireless Software and IoT Control Center are still under investigation.
Siemens is “evaluating the impact.” Moxa says none of its products are affected.

Then there’s the quiet group. As of my check, Rockwell, Hitachi Energy, Phoenix Contact, CERT@VDE (which covers WAGO) and Honeywell had no PHP2Shell entry on their public advisory pages. That isn’t a yes or a no. Silence just means you ask them directly.

My read, and this part is opinion: HMI web servers, historian portals, building management front ends and remote access gateways are exactly where a vendor-maintained PHP runtime hides. Those boxes often run older branches, which is the 8.1-and-older no-fix-release problem again. And that Cisco date tells you how long some fixes will take.

To be clear, no OT incident, PLC impact or utility compromise has been tied to PHP2Shell in anything I’ve seen.

Bottom line

This is a runtime bug, so it lives inside products you didn’t build. Patch what you own, chase vendors on what you don’t, and keep anything you can’t fix off the internet.

Find every web interface on your OT and building networks and ask each vendor in writing whether it embeds PHP, which version, and when a fix is coming.
Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your distro’s fixed package), and restart every worker.
Can’t patch? Take it offline or off the internet. VPN only, no port forwards, and watch for PHP processes spawning shells.

Stay safe, familia.

Javier