Three root shells in seven months. All from the same firewall.
CVE-2024-3400, CVE-2024-0012, and CVE-2024-9474 gave attackers unauthenticated root on Palo Alto firewalls twice in 2024. The pattern isn't bad luck. It's the architecture.
Palo Alto Networks’ PAN-OS picked up three CISA KEV entries in 2024, all exploited as zero-days, all granting root. Individually, each looks like the kind of critical-severity vulnerability that happens to every vendor eventually. Line them up, and they look like something else: a product that keeps offering unauthenticated root access from two different angles, seven months apart, to at least three distinct threat actor clusters.
The standard take is that Palo Alto had a bad year. The more interesting detail is that these three CVEs exploit two separate attack surfaces using different bug classes, and both paths end at the same place. That kind of convergence usually points at architecture, not luck.
April 2024: the GlobalProtect chain
CVE-2024-3400 is scored CVSS 10.0 for a reason. The GlobalProtect gateway on PAN-OS 10.2, 11.0, and 11.1 accepted a session cookie, wrote it to disk as a filename without validating that it was actually a UUID, and then let the telemetry subsystem execute whatever landed there. Two bugs, one CVE, unauthenticated root. watchTowr and Rapid7 both noted that Palo Alto assigned a single CVE to what is functionally a two-step exploit chain.
Volexity caught it in the wild. Their threat actor, tracked as UTA0218 and assessed as likely Chinese state-sponsored, had been testing the exploit since March 26, 2024, two full weeks before the April 12 disclosure. UTA0218 deployed a custom Python backdoor called UPSTYLE that persisted via .pth files in Python’s site-packages directory and read commands from firewall log entries to avoid obvious network signatures. Unit 42 named the campaign Operation MidnightEclipse.
The exposure surface was large. Censys narrowed the vulnerable population to roughly 22,500 GlobalProtect instances with the right configuration. After a public PoC hit GitHub on April 13, Mandiant’s M-Trends 2025 report counted more than a dozen separately tracked groups exploiting the same flaw within two weeks, including a RansomHub affiliate.
Palo Alto’s initial mitigations did not hold up. Disabling device telemetry was floated, then retracted on April 16 as ineffective. Threat Prevention signatures were found bypassable by independent researchers. Hotfixes shipped April 15, three days after disclosure.
November 2024: the management interface chain
Seven months later, two more CVEs. CVE-2024-0012 is an authentication bypass in the management web interface; CVE-2024-9474 is a privilege escalation to root via OS command injection in a PHP script called createRemoteAppwebSession.php. Chained, they give an unauthenticated attacker full root on the firewall OS, provided they can reach the management interface over the network.
The root cause of the auth bypass is specific and instructive. PAN-OS routes management traffic through Nginx as a reverse proxy to an Apache/mod_php backend. Nginx is supposed to set an X-pan-AuthCheck header to on before forwarding requests. In unpatched versions, it didn’t for certain request paths. The PHP backend trusted the header’s absence as implicit permission. watchTowr documented the full chain; a working public exploit was circulating by November 19, one day after the formal advisory.
Unit 42 called the campaign Operation Lunar Peek. Attribution for the initial wave was not published, but the post-PoC landscape was diverse: Arctic Wolf documented Sliver C2 deployments, webshells, cryptominers, and exfiltration of /etc/passwd and firewall configs across multiple unrelated intrusions. Shadowserver confirmed roughly 2,000 devices compromised out of approximately 13,000 exposed management interfaces, an 18% hit rate among the exposed population. The heaviest concentrations were in the US (554) and India (461).
The pattern underneath
Three CVEs, two attack surfaces, both ending at root. Here is what connects them.
The perimeter features are exposed by design. GlobalProtect portals and gateways face the internet because that is their job. You cannot mitigate CVE-2024-3400 by restricting access to trusted IPs, because the whole point of a VPN gateway is to accept connections from untrusted networks. Every parsing bug, every cookie handler, every session validator in that code path is zero-click attack surface that cannot be firewalled away. The same is true of the User-ID Authentication Portal, which picked up CVE-2026-0300 (an out-of-bounds write to root) in May 2026.
The management interface shouldn’t be exposed, but routinely is. Palo Alto’s documentation says to use the dedicated MGT port on an out-of-band network. CISA’s BOD 23-02, issued in June 2023, requires federal agencies to remove management interfaces from the internet. Despite both, Censys found 13,324 PAN-OS management interfaces publicly routable at the time of the November 2024 advisory. About 34% were in the US. Around 8% were on AWS, suggesting VM-Series deployments with management interfaces accidentally exposed to the internet.
The Nginx/Apache proxy chain is a recurring seam. CVE-2024-0012 exploited a missing authentication header in the Nginx-to-Apache handoff. Three months later, CVE-2025-0108 exploited a path-confusion bug in the same proxy chain. When two critical authentication bypasses hit the same architectural boundary within one quarter, the boundary has a design problem. Assetnote’s analysis of the Nginx/Apache path normalization mismatch is worth reading if you manage PAN-OS: the two servers parse URLs differently, and each mismatch is a potential auth bypass.
Everything runs on one kernel. PAN-OS is a single-OS monolith. Management plane, data plane, GlobalProtect, Captive Portal, and telemetry all share the same Linux kernel. Root on any component is root on all of them. There is no hypervisor boundary, no hardware isolation between the management processor and the data processor. This is common across most next-generation firewall architectures, but it means that every perimeter-facing bug class is also a management-plane compromise.
What the data actually shows about prioritization
If you run PAN-OS, the prioritization question is not “should we patch these CVEs” (they’re all CISA KEV-listed and over a year old). The question is whether your PAN-OS management and update posture accounts for the frequency of this class of event.
The KEV trajectory is accelerating. PAN-OS had two KEV entries before 2024. It added three in 2024 alone. Two more followed: CVE-2025-0108 in February 2025, CVE-2026-0300 in May 2026. That is five entries in 26 months, and the interval is shrinking. Fortinet’s KEV count is higher in absolute terms, but the PAN-OS trend line is steeper.
For the person setting patching priorities, the implication is that PAN-OS should be treated as a platform that will generate emergency patch cycles at roughly quarterly cadence. If your change management process requires two weeks to push a firewall hotfix to production, you will regularly be running vulnerable for the majority of the exposure window. A tested, sub-72-hour emergency patch procedure for network perimeter infrastructure is not optional; it is the baseline.
The management interface exposure is the most fixable part. Restricting management access to a dedicated out-of-band network or a jump host behind a VPN eliminates the entire CVE-2024-0012/9474 attack path and would have prevented every one of the 2,000 compromises Shadowserver documented. For the perimeter features like GlobalProtect, there is no equivalent shortcut. Those services face the internet by design, and the defensive options are limited to keeping PAN-OS current and running Threat Prevention signatures as a belt-and-suspenders layer.
What to watch
The structural question is whether Palo Alto will rearchitect the Nginx/Apache management proxy chain or the shared-kernel model, or whether the fix will continue to be individual patches against individual path-confusion or injection bugs. Two critical authentication bypasses in the same proxy layer in under four months suggests the audit surface is larger than what has been found so far.
The NSA’s February 2025 Edge Device Practitioner Guidance explicitly recommends assuming that edge devices can be compromised and designing network segmentation to limit blast radius. That guidance was written in response to exactly this class of incident pattern, across Palo Alto, Fortinet, Cisco, and SonicWall. If you are still treating your firewall as a trusted device rather than a managed risk, 2024’s PAN-OS record is a good reason to reconsider.
PatchDay Alert covered CVE-2026-0300 separately. That vulnerability hit the User-ID Authentication Portal, a different component, but the same architecture. The pattern is not self-correcting.
Sources
- CVE-2024-3400 PAN-OS Security Advisory
- CVE-2024-0012 PAN-OS Security Advisory
- CVE-2024-9474 PAN-OS Security Advisory
- Unit 42: Operation MidnightEclipse (CVE-2024-3400)
- Unit 42: Operation Lunar Peek (CVE-2024-0012/9474)
- Volexity: Zero-Day Exploitation of CVE-2024-3400
- watchTowr Labs: CVE-2024-3400 Analysis
- watchTowr Labs: CVE-2024-0012/9474 Analysis
- Mandiant M-Trends 2025
- Assetnote: CVE-2025-0108 Nginx/Apache Path Confusion
- Censys Advisory: CVE-2024-0012
- Shadowserver: Compromised PAN-OS Devices
- CISA BOD 23-02: Mitigating Risk from Internet-Exposed Management Interfaces
- NSA Edge Device Practitioner Guidance (Feb 2025)
- Rapid7: CVE-2024-3400 Analysis
Share
Related field notes
-
CISA says patch by Friday. Palo Alto's fix ships next Tuesday.
CVE-2026-0300 is an unauthenticated RCE in PAN-OS Captive Portal, exploited since April 9 by a state-aligned actor. The KEV deadline is May 9. The first patch lands May 13. Here's what to do with the four days in between.
-
SAP NetWeaver was owned for ten weeks before anyone said anything
Five threat groups were already inside SAP NetWeaver when the emergency patch shipped. One confirmed victim reported multi-billion dollar profit impact. SAP's initial workaround guidance was later marked 'Do Not Use.'
-
Oracle blamed its customers for a zero-day it hadn't patched
Oracle's first public statement during active Cl0p exploitation told customers the breach was their fault for not applying a patch that didn't exist. The correction came Saturday night, behind a paywall.
One email, every weekday morning.
You're in. Check your inbox.