PHP2Shell: How Hackers Took Over Firewalls Through Their Admin Page

PHP2Shell is no longer theoretical

For a week the security world braced itself over PHP2Shell, the pair of critical PHP flaws (CVE-2026-109618 and CVE-2026-109619, both CVSS 9.2) patched by the PHP project on 21 October (PHP 8 changelog). Now we know what it looks like when somebody actually uses it, and it isn’t a web server getting defaced. It’s firewalls. Specifically, the admin pages of Palo Alto Networks firewalls, some of them belonging to a US government-affiliated organisation.

I want to cover this on IoTPortal for one reason. The thing that got hit wasn’t “a website running PHP”. It was an appliance with a PHP-powered web admin interface, bundled into firmware and sat on the internet. That description fits a depressing number of devices in our world: routers, gateways, NAS boxes, industrial edge kit. If you look after any of that, this one is worth five minutes of your time.

What happened

Israeli security firm Dream got hold of the toolkit of a suspected China-nexus group and reconstructed the campaign. Palo Alto’s Unit 42 has independently verified the tooling and confirmed Dream’s results, and Palo Alto has published its own PHP2Shell advisory.

The attackers used FOFA, an internet-scanning search engine, to find around 19,000 Palo Alto firewalls with their management interface reachable from the internet. From there they rooted 25 servers across the US, Japan, Taiwan and South Korea. Three were in a US government-affiliated environment.

The chain had two parts, and it’s the second part that should make embedded people sit up:

• PHP2Shell got them in. The PAN-OS management web UI and XML API run on PHP. A single crafted multipart POST request abuses PHP’s session upload progress handling and corrupts memory before any application code runs. No password, no user interaction. That gave them code execution as the low-privilege “nobody” user.
• Fragnesia made them root. They then used CVE-2026-46300, a Linux kernel privilege escalation in the XFRM ESP-in-TCP code, to go from “nobody” to full control of the box. Fragnesia went public back in May and affects major distributions with kernels released before 13 May 2026.

Start to finish, under 15 minutes. Once inside, the attackers tunnelled into the internal network, ran around 40 custom post-exploitation scripts, went after Active Directory and pulled credentials. Dream believes the tunnel is likely still running.

The timeline is the scary bit

Two days from upstream patch to root on a government firewall. And the vendor fixes, quite reasonably, could only follow the upstream ones, rolled out branch by branch. That gap between “the component is fixed” and “the product you own is fixed” is where this whole attack lived. If you’ve ever waited for a router vendor to pick up an OpenSSL or kernel fix, you’ll know the feeling.

What has happened since

The Palo Alto campaign is the confirmed headline, but it isn’t the whole story. In the two weeks since the fix, PHP2Shell has turned into a slow-motion audit of every product that quietly ships PHP inside it.

• The affected list keeps growing. The Dutch NCSC is tracking a public inventory of products with a PHP dependency. By 28 October it listed 757 products: 218 vulnerable, 144 fixed, 40 not affected and 354 still under investigation. That last number is the one that worries me.
• It’s not just Palo Alto. Singapore’s Cyber Security Agency issued an alert on 3 November naming Cisco Duo Access Gateway and Expressway, Citrix NetScaler ADC and Gateway, F5 BIG-IP APM and the BIG-IP Configuration utility, and the Siemens RUGGEDCOM APE1808 as affected, while noting active exploitation so far has been reported against Palo Alto. The NCSC-NL inventory also lists Cisco’s Unified Industrial Wireless Software as vulnerable, which puts PHP2Shell squarely into industrial wireless kit.
• NAS and storage. QNAP is confirmed affected, Synology has shipped updated PHP packages, and Western Digital has published its own analysis.
• Old PHP is the real problem. According to watchTowr, every way of serving PHP is in scope (Apache mod_php, PHP-FPM, php-cgi, LiteSpeed and FrankenPHP), with mod_php the highest risk because the attack lands before the application’s code runs. PHP 7.4, 8.0 and 8.1 have no official release, only backports and distro packages, and PHP 7.3 and older are affected with no fix at all. Embedded devices are exactly where you find PHP that old.
• A follow-up bug. A separate issue, CVE-2026-115560, surfaced on 23 October. It needs an unusual session configuration and isn’t fixed by the 21 October releases. PHP’s interim advice is to switch off session upload progress where you control the runtime.
• Exploit noise. Mallory counted 859 public GitHub repos claiming PHP2Shell exploits by 1 November. Only about a quarter contain exploit code at all, none had been confirmed working end to end, and a handful came with a web shell already bundled in. If your team grabs a “checker” from GitHub, read it before you run it.
• Generic web servers too. Honeypots have recorded in-the-wild attempts against ordinary Apache mod_php installations, including one running PHP 8.4.26, one release behind the fix.

Most of the names above are enterprise kit, but they’re the canaries. The routers, gateways and controllers further down the food chain usually get assessed last and patched slowest, and many will never be assessed at all.

Why this matters for IoT, not just firewalls

Here’s what I think the real lesson is. The compromised firewall in Dream’s write-up was running PHP 8.0.30. PHP 8.0 went end of life in November 2023. That isn’t a dig at Palo Alto in particular; it’s how appliances work. The vendor freezes a runtime into the firmware, ships one build per release, and that build quietly ages while the world moves on. It’s the same story as OT equipment that outlives its support, just with a firewall badge on it.

Field Effect made a point I hadn’t considered: public PHP2Shell exploits reportedly struggled against generic web servers because memory layouts vary from build to build. Appliances are the opposite. Every unit on a given firmware version runs the identical PHP binary, so once an attacker profiles it, it works everywhere. Dream says these attackers decrypted PAN-OS firmware and built memory profiles for nine versions. Uniform firmware is a gift to an exploit writer.

Now apply that to the kit we deal with:

• Industrial edge. Siemens’ RUGGEDCOM APE1808, an application processing engine that slots into RUGGEDCOM switches and routers in substations and plants, runs PAN-OS, and Siemens has issued advisory SSA-566512 for PHP2Shell. So this isn’t only an IT problem; it’s on OT networks too, and OT and IT patch on very different clocks.
• NAS and storage. Synology, QNAP, TerraMaster, Ugreen and Asustor have all been dealing with PHP2Shell exposure in their software, with patches at very different stages.
• Routers and gateways. Not every router web UI is PHP. Plenty use Lua, compiled CGI binaries or Node. But some do, and almost all of them run an embedded Linux kernel that rarely gets updated. Router web interfaces are a favourite target anyway, as the recent critical Teltonika RutOS flaw showed. Fragnesia is a reminder that the second stage of an attack doesn’t care what language the web page was written in.

And this is where my particular hobby horse comes in. A cellular router on a public IP SIM with its web admin open on the WAN side is exactly the same pattern as those 19,000 firewalls: an admin page reachable from anywhere, found by a scanner in seconds. I see it far too often. It works fine for years, right up until it very much doesn’t.

What to do

1. Get admin interfaces off the internet. Restrict management to trusted internal addresses, or reach devices over a VPN or private APN. Palo Alto’s own mitigation advice leads with exactly this, and it applies to every device you own.
2. Patch Palo Alto kit now. Fixed PAN-OS releases are out for 12.2, 12.1, 11.2, 11.1 and 10.2 (12.2 needs 12.2.4-h1 or later). Panorama is affected too. If you run a RUGGEDCOM APE1808, follow Siemens SSA-566512.
3. Update PHP anywhere else you run it. That means 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, including PHP packages on NAS boxes. Where you control the runtime and can’t patch yet, PHP’s interim advice is to set session.upload_progress.enabled = 0 and restart PHP workers.
4. Ask your other vendors two questions. Does your web UI use PHP, and which version? When will your firmware pick up the Fragnesia kernel fix? A good vendor will answer quickly. A slow answer tells you something too.
5. Assume compromise if you were exposed. If a PAN-OS management interface was internet-facing during late October, patching alone isn’t enough. Review logs, rotate credentials and check Active Directory for unexpected activity. Our OT security audit checklist is a decent place to start.
6. UK organisations: sign up for NCSC Early Warning. It’s free, and it tells you when the NCSC spots vulnerable or exposed services on your public IP ranges, which is exactly the kind of admin page this campaign went looking for.

A word on the AI angle, because it’s already doing the rounds. Dream did find AI coding tools on the attackers’ systems, including Claude Code and an AI-assisted scanning platform configured with DeepSeek and Kimi models. But Dream is clear this was not a fully autonomous attack. People built and ran this chain. The defence is the same boring, effective one it’s always been: don’t put admin pages on the internet, and patch.

Further reading

Pass it on

If you work in IT, networks or OT, or you know someone who looks after a fleet of routers, firewalls or gateways, please send this to them today. One forwarded link and one quick check of an admin page could save somebody a very bad week.