Two Days From Patch to Root: How a PHP2Shell Chain Took Over 25 Palo Alto Servers, and What “AI-Assisted” Really Means

By Thorsten Meyer | October 30, 2026 | ThorstenMeyerAI.com

Buying for a business?Offer from Amazon

Get business pricing on tech for your team

• Business-only prices and quantity discounts
• Tax-exempt purchasing
• Multiple users, one account, clear invoices

Create a free Business account →Free to register

As an affiliate, we earn on qualifying purchases.Hide

On October 21, the PHP project shipped fixes for two critical flaws now known as PHP2Shell. On the evening of October 23, about two days later, an attacker ran an automated batch against 240 firewalls and came out with root access, the all-powerful administrator account, on 24 of them. The next morning they used one of those firewalls as a stepping stone into a US government-affiliated network, took over a 25th server inside it, and went after the organization’s Active Directory, the system that decides who may log in to what.

That is the account Dream, an Israeli AI security company, published on October 26 and updated on October 29. Palo Alto Networks, whose PAN-OS firewalls were the targets, says its Unit 42 researchers independently verified the attacker’s tools and results. Dream also found AI tools on the attacker’s servers, which is why the story is travelling as an “AI-built exploit chain”. Here is what is confirmed, what “AI-assisted” does and does not mean in this case, and what companies and site owners should do now.

Key takeaways

• Two bugs, chained. The attacker combined PHP2Shell (CVE-2026-109618 and CVE-2026-109619) with Fragnesia (CVE-2026-46300), a Linux kernel bug made public in May. The first gave code execution as a powerless user on the firewall’s management web server, the second turned that into root. No password needed. Dream says the whole chain, up to a permanent root back door, takes under 15 minutes (Dream).
• 25 servers: 24 firewalls plus one management server. The targets were in the United States, Japan, Taiwan and South Korea. 22 of the 24 rooted firewalls were left “parked” with a hidden web shell. Two belonged to a US government-affiliated organization, and through them the attacker reached the internal server that manages all of its firewalls.
• The fix for PHP existed. The fix for the firewall did not. PAN-OS ships its own copy of PHP, version 8.0.30 according to Dream. Palo Alto published its advisory on October 21, but fixed builds for the attacked 12.1 and 12.2 branches only shipped between October 27 and 29. Until then, the protection was to keep the management page off the internet (Palo Alto Networks).
• “AI-assisted” is an inference, not a proof. Dream found the coding assistant Claude Code installed, and the Chinese models DeepSeek and Kimi configured in an offensive-security platform called aiscan. Dream says it has “no direct evidence” that AI tools wrote the exploit or the scripts, and that this “does not appear to be a fully autonomous” attack.
• The real lesson is old. An admin page on the open internet, a kernel bug five months old, an Active Directory without account lockout. AI may have made the attacker faster. Every door they walked through was already open.

Products Worth Considering

Logitech MX Keys S Wireless Keyboard, Graphite

AmazonView Latest Price

DJI Osmo Mobile 7P Phone Gimbal with Mic Mini Transmitter, Infinity Black

AmazonView Latest Price

Samsung 27-Inch Odyssey QD-OLED G8 4K 240Hz Gaming Monitor

AmazonView Latest Price

As an affiliate, we earn on qualifying purchases.

The short answer

Think of a firewall as the security desk at the entrance of an office building. Its management page is the back office behind the desk, where the guards change the rules: who may enter, which doors open, which badges work. That back office should only be reachable from inside the building. On the attacked firewalls, it was reachable from the street.

The attacker then used two known tricks in a row. PHP2Shell let them run commands in that back office, but only as a powerless temp worker: on these firewalls the web server runs as a user called “nobody”, and the system’s protections stopped that user from changing anything important (Dream). The kernel bug Fragnesia let them overwrite a file they should only be able to read, and with that they switched off the password check for the administrator account. From there it was a short step to a permanent, hidden back door.

None of this needed a new kind of attack. It needed preparation, speed and targets that had left the back office facing the street. I will not go deeper into the mechanics. Dream’s post is detailed enough, and nobody needs a recipe from me.

What happened, step by step

Dream’s timeline, with the vendor and government dates added:

• May 13 to 23, 2026: Fragnesia, a Linux kernel privilege-escalation bug, is disclosed with a public exploit, fixed in the kernel and assigned CVE-2026-46300 (oss-security; NVD).
• October 8: the attacker sets up the AI platform aiscan with DeepSeek and Kimi, according to Dream’s timeline.
• October 21: PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 and urges everyone to update (php.net). Palo Alto publishes its advisory the same day; fixed PAN-OS versions are “upcoming”.
• Before October 23: about 19,000 PAN-OS firewalls with internet-facing management pages are found through FOFA, a Chinese search engine for internet-connected devices, similar to Shodan. A custom scanner gets version answers from about 5,000. Filtered by country and version, 240 targets remain.
• October 23, 18:14 to 21:55 UTC: an automated batch attacks the 240, five at a time. 24 are rooted. The first government-affiliated firewall falls at 18:14 and crashes shortly after, likely from the roughly 900 MB of attack traffic.
• October 24, 10:09 UTC: a second firewall of the same organization is rooted in a dedicated run. Within the hour, a tunnel back to the attacker and persistence that survives reboots are in place. At 11:35 UTC the internal firewall management server falls through that tunnel: server number 25. Attacks on Active Directory follow.
• October 25: Dream’s researchers find the attacker’s artifacts.
• October 26: Dream publishes. CISA, the US cybersecurity agency, adds both PHP2Shell CVEs to its catalog of exploited vulnerabilities and gives federal agencies three days (CISA KEV).
• October 27 to 29: fixed PAN-OS builds for the 12.2 and 12.1 branches ship. On October 28, CISA adds Fragnesia to its catalog and notes that it “can be chained” with PHP2Shell “to implant PHP webshells and run commands as root”.
• October 29: Unit 42 writes that it “independently verified the same attacker’s tooling and confirmed the reported results” (Unit 42).

Two gaps stand out. From the PHP fix to the first root: about two days. From the second government firewall to the internal management server: under 90 minutes, per Dream.

Why a famous bug still took real work

PHP2Shell was famous before it was exploited. The Register counted “hundreds” of proof-of-concept repositories on GitHub, yet the first reports of successful attacks only came days later (The Register). The Hacker News quotes a member of a criminal forum, via the threat intelligence firm Flare, who called the public code “unexploitable” against real targets, because a working attack needs memory addresses that differ for every single build of PHP (The Hacker News; reported, I could not check the forum post).

This attacker did that homework. Dream says they obtained PAN-OS firmware, decrypted it, extracted the PHP library and built 11 version profiles with the exact addresses for each build. One base profile was tested against a running copy in a lab (“calibrated”); the others were calculated from the files (“provisional”). Dream counts 9 exploitable versions, and calls the exploit “a custom, non-public build, not a copy of any known public exploit”.

That is the part worth remembering. A famous bug is not automatically an easy one. But an attacker who is willing to do the tedious work for one specific product gets a tool that runs against thousands of identical boxes. And firewalls are very identical boxes.

From 19,000 found to 25 taken

Dream’s numbers read like a sales funnel:

• About 19,000 PAN-OS firewalls with management pages reachable from the internet, found through FOFA.
• About 5,000 answered the attacker’s version scanner.
• 240 were in the four target countries and ran a version the attacker had a profile for.
• 24 were rooted in the batch run, one in ten of the targets.
• 1 more: the internal management server, reachable only through the tunnel.

What the attacker did next says a lot. For 22 of the firewalls: nothing beyond a tiny hidden web page that runs commands as root. No tools, no tunnels. Dream calls them “effectively owned and parked”, ready for a return visit. The two government-affiliated firewalls got the full treatment. The first one’s configuration file revealed the organization’s internal map, Dream says: domain controllers, a single sign-on server, a code repository, the VPN gateways and the central firewall management server. The attacker then built a dedicated campaign for the second firewall.

Palo Alto describes the scale from its side: “approximately .02%” of its global installed base “has internet-facing management interfaces configured and were impacted”, and each of those customers was contacted individually, Unit 42 says. That is the vendor’s own count; I cannot check it.

From the firewall to the keys of the house

The most important part of Dream’s report is not the exploit. It is what happened after it.

The internal firewall management server talks to Active Directory, because it checks VPN users’ passwords there. For that it stores a service account password, encrypted. With root on the server, the attacker had the master key and decrypted it, Dream says. With that account they listed every user and group in the domain, then tried organization-themed passwords against every single account. The domain had no account lockout configured, so the guessing could run without limit. They also tried to create hidden user and computer accounts, looked for paths to higher privileges, and went after the signing key of the single sign-on system, which would let them forge logins.

Whether any of that worked is unknown. The results stayed on the compromised server, and Dream did not recover them. What Dream does list as in the attacker’s hands: a tunnel into the network that is “likely still active”, root web shells on two firewalls and the management server, the full user directory, the decrypted service account, and private keys taken from the firewall, including certificate and device keys.

That is the pattern we keep seeing on network edge boxes: the box is not the prize, it is the key ring. We described the same logic for Cisco’s SD-WAN controllers in They Came for the Keys, Not the Data.

What “AI-assisted” means here, and what it doesn’t

Dream lists three findings on the attacker’s infrastructure:

• Claude Code, Anthropic’s AI coding assistant, “had been installed”.
• aiscan, which Dream calls “an AI-powered offensive security platform”, was configured with the Chinese language models DeepSeek and Kimi. Its session logs contain user messages in Chinese.
• API keys for FOFA, the device search engine.

Then comes the sentence that matters: “While we have no direct evidence that the AI tools were specifically used to write the exploit or the post-exploitation scripts, the code structure, commenting style, and consistency across ~40 scripts suggest AI-assisted development. That said, this operation does not appear to be a fully autonomous nation-state attack.”

Read carefully, that is three different levels of evidence:

1. Shown: the tools were present and set up. Installed is not the same as used, and configured is not the same as successful.
2. Inferred: the scripts look as if AI helped write them. Style is a weak signal. Plenty of people write tidy, well-commented code, and plenty of AI-written code is messy.
3. Not shown: that any AI found the bug, built the exploit, calibrated the version profiles or ran the operation. Dream credits the hard parts, getting and decrypting firmware and calibrating the exploit in a lab, to the attacker’s “significant effort into vulnerability research”.

My reading: the most plausible role for AI tools here is the one they play in every software team right now. They speed up the volume work: scanners, batch runners, parsers, 40 helper scripts. That matters, because volume work is what turns one working exploit into a campaign against 240 targets in one evening. But the story is not “AI hacked 25 servers”. It is “a prepared team worked fast, and its toolbox included AI”.

Two more points, for fairness. First, the tools span vendors and countries: a US coding assistant next to two Chinese models. Nothing in Dream’s report says which of them, if any, mattered, so I won’t guess. Second, AI sits on the defending side of this story too. PHP2Shell itself was found by researchers at Calif, OpenAI and Wiz with the help of frontier models, as we told in The 22-Year Road to PHP2Shell, and Dream says it ran this investigation with its own autonomous research product. The window between a fix and an attack is shrinking from both ends, a point we made with Anthropic’s lab results in Anthropic’s AI Built Five Working Attack Chains.

And one point for anyone writing company policy: the usage rules of AI vendors do not stop an attacker who runs whatever models they like on their own servers. Defence cannot depend on attackers being denied tools. It has to depend on closed doors.

Who is behind it

Dream does not name a threat actor. It lists indicators that point to a Chinese-nexus operation: the choice of the four target countries, the Chinese search engine FOFA, a Chinese-developed tunnelling tool, the Chinese models in aiscan, server clocks set to China Standard Time and Chinese-language prompts. According to Dream, Unit 42 tracks the activity as CL-UNK-1280 and attributes it to a Chinese-speaking attacker in the UTC+8 time zone; I could not find that designation on Unit 42’s public page. “Chinese-nexus” and “state-sponsored” are different claims. Dream speaks of “potential nation-state adversary efforts”, not of a confirmed state operation.

This is a separate case from VAPOR PANDA, the China-nexus group that CrowdStrike reported on October 29 for running its intrusions with an AI agent framework: different actor, different evidence.

What Palo Alto and CISA say

• What is affected: PAN-OS on PA-Series and VM-Series firewalls and on Panorama, in the 10.2, 11.1, 11.2, 12.1 and 12.2 branches. Only the management web interface is affected, meaning the web UI and the XML API, including any regular network interface with a management profile attached. Palo Alto says the GlobalProtect portal and gateway, Clientless VPN and Captive Portal are not affected. Dream wrote that the management web server “also fronts the GlobalProtect portal”; on what is affected, follow the vendor.
• Severity: critical, with urgency raised to “highest” on October 27; exploitation status “attacked”.
• Fixed builds: for example 12.2.4-h1, 12.1.10-h3 (12.1.7-h11 and 12.1.4-h13 on older maintenance lines), 11.2.16-h1, 11.1.16-h4 and 10.2.18-h13. The advisory names the exact hotfix for every maintenance line; unsupported versions need an upgrade to a supported fixed version. According to Palo Alto, the same hotfixes also fix the Brotli compression bug we explained in Broccoli2Shell, with one exception, 11.2.10-h16.
• Stopgaps: threat prevention signatures (Threat ID 543004 and others), which only protect if management traffic is routed through the firewall’s inspection. The simpler advice from the same advisory: allow management access only from trusted internal addresses or a single jump box.
• CISA: both PHP2Shell bugs in the exploited catalog since October 26 (federal deadline October 29), Fragnesia since October 28 (deadline October 31).

One open question: Palo Alto says its hotfixes “interrupt the observed exploit chain”, which they do by fixing PHP. Its advisory does not say whether the kernel bug Fragnesia is fixed in PAN-OS as well. With the front door closed that matters less, but it is a fair question for your account team.

What this means for companies

In order of priority:

1. Take management interfaces off the internet, today. Not only on Palo Alto devices: firewalls, VPN gateways, storage systems, backup appliances, printers. Allow admin access only from internal addresses or a jump box. Check regular interfaces too; on PAN-OS, an interface with a management profile counts.
2. Patch PAN-OS to the fixed hotfix for your exact maintenance line. Use the advisory, not a summary like this one. CISA gave federal agencies three days, a sensible yardstick for everyone else (my suggestion).
3. If your management page was reachable from the internet at any point since October 21, assume compromise until you have checked. In Dream’s account, 22 of 24 victims showed nothing but a small web shell. Use Palo Alto’s guidance and indicators, look for unknown files in web directories, unknown services and boot scripts, and unexpected outbound connections from the firewall. Talk to your incident responder before you reboot or reinstall a suspect device, so evidence is not lost (my advice).
4. Rotate what lived on the box. Service account passwords stored in the configuration (for example for LDAP or RADIUS), certificates and private keys, high-availability keys, admin passwords. Dream lists exactly these as taken in the government case.
5. Harden Active Directory against the next step. Set an account lockout policy; the attacked domain had none. Review who may add computer accounts to the domain; Dream says the attacker tried to abuse that default. Check that your single sign-on validates certificates. Alert on new user and computer accounts.
6. Make an inventory of appliances that embed PHP or other runtimes. Firewalls, VPNs, storage, backup appliances and portals often ship their own copy, and they are only fixed when the vendor ships a firmware update. We warned about exactly this on October 22 in PHP2Shell and a Node.js Security Release on the Same Day. Ask each vendor for a date.
7. Plan for 48 hours. That was roughly the gap between the PHP fix and mass exploitation here. A monthly patch cycle cannot keep pace with that on internet-facing systems; a separate fast lane for edge devices can.
8. Watch for root-level changes on appliances. Regular configuration exports and comparisons, file integrity checks where the vendor supports them, and alerts on new outbound tunnels from management networks.
9. Do not count on AI rules to protect you. AI usage policies govern your own staff and suppliers. Attackers bring their own models.

For the other direction, attacks on AI tools themselves, see Attackers Now Go After Your AI Tools. This week’s Fortinet firewall fixes are in This Week in Security.

What this means for users and site owners

Most people will never touch a Palo Alto firewall. Three things still apply.

1. If you run a website on PHP, ask your host. PHP2Shell affects ordinary PHP web servers, not just firewalls. Palo Alto’s own scanning service counts more than 22.6 million exposed instances that are potentially vulnerable (its count, not mine). The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older versions only get vendor backports, and a backported fix often keeps the old version number. So ask your hosting provider one direct question: “Is the PHP serving my site patched for CVE-2026-109618 and CVE-2026-109619?” If the answer is vague, or you are on PHP 8.1 or older without vendor support, plan a move to a supported version.
2. Close admin pages at home and in the small office. Routers, network storage and cameras have management pages too. Switch off remote management unless you really need it, and install firmware updates.
3. If you are asked to reset a password, do it, and expect phishing. Password guessing works because people reuse simple, predictable passwords. Use a password manager, a different password for every account and multi-factor sign-in. Go to the login page you know yourself instead of clicking a link in an unexpected message.

Honest limits

• One company’s forensic account. The step-by-step story is Dream’s, based on artifacts it recovered. Unit 42 says it verified the tooling and results but has not published its own detailed account. Dream sells the research product it used, so the report is also marketing. Confirmed independently: the CVEs, active exploitation against PAN-OS management interfaces (Palo Alto, CISA) and the chain itself (CISA’s catalog note).
• The AI part is the weakest part. Tools present, scripts that look AI-assisted, and in Dream’s own words no direct evidence that AI wrote the exploit. Treat headlines about an “AI-built” attack accordingly.
• Attribution rests on indicators, not a name. Dream names no actor; the Unit 42 designation is reported by Dream and not visible on Unit 42’s public page.
• The damage inside the government network is unknown. Whether passwords were guessed, accounts created or signing keys stolen stayed on the compromised server.
• Small disagreements between sources. Dream says the management web server “also fronts” the GlobalProtect portal; Palo Alto says GlobalProtect is not affected. Some outlets count 24 servers, others 25; both are right, 24 firewalls plus one management server. The Hacker News dates the activity to October 25, the day Dream found it; Dream’s timeline puts the attacks on October 23 and 24.
• Vendor counts. The 0.02 percent and the 22.6 million are Palo Alto’s own figures.
• Fragnesia on PAN-OS. The advisory does not say whether the kernel bug is fixed in PAN-OS; the hotfixes are described as breaking the observed chain.

Verdict

This was not magic, and it was not a robot uprising. It was a well-prepared team that did the tedious work a famous bug required, used every tool it had, AI included, and found 240 back offices facing the street. Two days was enough. Close the management door, patch to the fixed build, and if the door was open, go looking for the guest who may still be inside.

Sources

• Dream Research, “Chained PHP2Shell Exploit Roots 25 Servers, including US Government Servers”, October 26, 2026, updated October 29, 2026
• Palo Alto Networks Security Advisory, “Impact of Critical Vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619) on Palo Alto Networks Products”, first published October 21, 2026, updated through October 29, 2026
• Unit 42, “Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619”, updated October 29, 2026
• PHP Group, security advisory and releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, October 21, 2026
• NVD, CVE-2026-109618 · CVE-2026-109619 · CVE-2026-46300 (accessed October 30, 2026)
• CISA, Known Exploited Vulnerabilities catalog (version 2026.10.29: PHP2Shell added October 26, Fragnesia added October 28, 2026)
• oss-security, “Linux kernel LPE (fragnesia)”, May 13, 2026 and “Dirty Frag variants: fix merged into netdev”, May 21, 2026
• The Register (Jessica Lyons), “Suspected Chinese attackers built a custom PHP2Shell exploit and rooted 25 servers”, October 29, 2026
• The Hacker News, “PHP2Shell Attack Roots 25 Servers, Breaches U.S. Government-Affiliated Network”, October 2026

Related on ThorstenMeyerAI.com: PHP2Shell and a Node.js Security Release on the Same Day · The 22-Year Road to PHP2Shell · Broccoli2Shell · Attackers Now Go After Your AI Tools · Anthropic’s AI Built Five Working Attack Chains · They Came for the Keys, Not the Data

Researched and drafted with AI assistance, including Anthropic’s Claude.