Same Class, Different Door: CVE-2026-0310 and PAN-OS's Second Root-RCE Buffer Overflow of 2026

Palo Alto Networks disclosed CVE-2026-0310 on September 10, 2026: an out-of-bounds write in PAN-OS’s XML processing that lets an unauthenticated attacker execute arbitrary code as root on PA-Series hardware firewalls. That sentence should sound familiar if you were reading this site back in May, because it’s almost word-for-word what I’d have written about CVE-2026-0300. Same vendor, same operating system, same privilege level, same CWE, four months apart. That’s not a coincidence worth skipping past with a one-line “patch immediately” and moving on. It’s worth putting the two advisories side by side and asking what’s actually different, and what isn’t.

CVE-2026-0310: what’s broken this time

The bug lives in PAN-OS’s XML parsing. An attacker with network reach to a vulnerable management web interface or dataplane interface sends specially crafted XML, and the parser writes past the end of a buffer it shouldn’t. Palo Alto’s own classification is CWE-787, out-of-bounds write, and they’ve given it the highest suggested urgency they issue. No authentication, no user interaction, though the vendor rates actual exploitation as high complexity, which tends to mean the memory layout has to line up just right rather than there being a simple crafted-request-and-done exploit sitting on GitHub already.

The scoring is worth reading carefully rather than skimming to a single number. Palo Alto gives it a CVSS-B (base) score of 9.2 and a CVSS-BT (base plus threat) score of 7.2. The threat modifier pulling the number down, rather than up, tells you the vendor currently has no evidence of active exploitation or public proof-of-concept, so the “threat” component of their scoring formula is doing what it’s meant to and discounting a bug with no observed real-world pressure yet. Worth remembering that number moves in only one direction from here.

Impact varies sharply by product, which is the detail most likely to get lost if you’re skimming a summary rather than the advisory. On physical PA-Series appliances, successful exploitation is root-level code execution, full control of the firewall. On VM-Series firewalls, the same underlying flaw only gets you a denial-of-service: the process crashes rather than executing attacker code, presumably because the memory layout and available gadgets differ enough between the hardware and virtual builds that the write corrupts something that crashes cleanly instead of something exploitable. Prisma Access and Cloud NGFW are also technically affected, but Palo Alto rates the practical risk lower there because reaching the vulnerable code path requires an authenticated user and the network path is more restricted than an open management interface.

Affected versions span a wide range of branches: everything before 12.2.3, 12.1.10, 11.2.13-h2, 11.1.16-h2, and 10.2.18-h10, which in practice means most maintenance builds across the 10.2 through 12.2 lines released before early September. There’s no workaround. Palo Alto’s mitigation advice is the standard perimeter-hardening line: keep management interfaces off untrusted networks, and where you can’t avoid administering the box remotely, put a jump box in front of it rather than exposing the interface directly. As of September 9, the day before disclosure, Palo Alto said it found this one internally and has no evidence of exploitation in the wild.

CVE-2026-0300: the one from May, and how it actually played out

Palo Alto published CVE-2026-0300 on May 6, 2026. The vulnerable component was PAN-OS’s User-ID Authentication Portal, also called Captive Portal, a non-default feature that maps IP addresses to usernames for policy purposes. Same bug class, CWE-787, same headline impact: an unauthenticated attacker sends specially crafted packets and gets root-level code execution on PA-Series and VM-Series firewalls alike. The CVSSv4 score was 9.3, and unlike CVE-2026-0310, there was no ambiguity about real-world impact: this one was found because it was already being exploited.

The timeline is instructive. Palo Alto’s advisory went out May 6 acknowledging limited in-the-wild exploitation against internet-exposed Authentication Portals. CISA added it to the Known Exploited Vulnerabilities catalog the same week and set a remediation deadline of May 9, three days later, which is about as short a KEV window as CISA sets and a fair signal of how seriously they read the threat. No patch existed yet at that point; the only available response was Palo Alto’s workaround of disabling the Authentication Portal entirely if it wasn’t in active use, or restricting it to trusted zones if it was. Fixed builds rolled out in batches through May and into June.

Unit 42’s own threat brief attributed the observed exploitation to CL-STA-1132, a cluster they assess as likely state-sponsored. Post-exploitation activity included deploying open-source tunneling tools and enumerating Active Directory, consistent with an actor using the firewall as a foothold rather than an end in itself, which tracks with the wider pattern this site keeps coming back to when covering perimeter-device CVEs: the firewall is rarely the target, it’s the door.

Same CWE, same privilege, different door

Put the two advisories next to each other and the shape is nearly identical. Both are CWE-787 out-of-bounds writes. Both hit PAN-OS specifically on the PA-Series and VM-Series product lines, though with the interesting VM-Series wrinkle of DoS-only impact showing up again in the September advisory, which suggests this might be a structural property of how PAN-OS handles memory differently across hardware and virtual builds rather than a one-off. Both are reachable without authentication. Both carry the vendor’s highest urgency rating.

What’s different is the entry point and, so far, the real-world consequence. CVE-2026-0300 lived in a specific, optional feature: the Authentication Portal, something an administrator has to deliberately enable. That narrows the exposed population but also means every affected box was one that had actively turned on a feature, which is a smaller and arguably more security-conscious population than “every PAN-OS box running XML processing,” since XML parsing isn’t a feature you opt into, it’s just part of how the management plane works. CVE-2026-0310’s broader default attack surface is offset, for now, by the higher exploitation complexity Palo Alto assigned it and the complete absence of observed attacks. CVE-2026-0300 had the opposite profile: a well-defined, narrower feature, but one already being hit by a capable actor before the advisory even existed.

There’s a methodological point worth drawing out too. Palo Alto’s May advisory used a static CVSSv4 base score. The September one splits base and threat scores explicitly, 9.2 and 7.2 respectively, which is the same dynamic-scoring approach I flagged when covering CVE-2026-0257 back in August: Two Ways to Lose a VPN Gateway. Palo Alto’s FAQ explains the logic directly: the base score reflects the vulnerability as designed, and the threat score adjusts continuously against real proof-of-concept releases and observed exploitation. It means the number attached to CVE-2026-0310 today is not the number it’ll carry in a month if someone publishes a working exploit. Worth checking back on this one rather than filing the 7.2 away as final.

Two root-RCE buffer overflows in the same OS family within four months isn’t damning on its own; every major firewall vendor ships CVEs against C-based, high-performance network stacks, and the class of bug (an out-of-bounds write) is one of the oldest and hardest to fully eliminate in that kind of codebase. But it is a legitimate signal to look at where else in PAN-OS parses untrusted input directly on an internet-facing interface, and to treat “we found this internally, no exploitation yet” advisories with exactly the urgency Palo Alto is asking for, rather than with the relaxed patch cadence that “not yet exploited” can tempt people into.

A pattern bigger than one vendor

None of this is unique to Palo Alto, and it’s worth being honest about that rather than letting a Palo Alto-focused post read like a Palo Alto pile-on. Root-level remote code execution on perimeter security appliances has been the defining vulnerability class of 2026 across the entire industry. Cisco disclosed a root-RCE in Nexus 9000 switches the same day as an unrelated IOS XR hardening bundle in early September: Same Day, Two Advisories. Cisco Catalyst SD-WAN Manager had a root-RCE reachable through nothing more exotic than a CSV upload: One CSV Upload From Root. On the Fortinet side, FortiSandbox got a shell via an exposed VNC service: Start VNC, Start a Shell, and FortiManager’s FGFM protocol had a certificate-trust gap that let one device impersonate another: Wearing Someone Else’s Certificate. FortiWeb had a RADIUS wildcard bug letting anyone in through the admin GUI: The Wildcard That Wasn’t.

The common thread across every one of those, and across both PAN-OS CVEs covered here, isn’t a shared root cause; the specific bugs are genuinely different (buffer overflows, certificate trust confusion, RADIUS misconfiguration handling, unauthenticated management services). The common thread is architectural: these are all internet-facing management or control-plane surfaces on devices whose entire job is to sit at the network edge. Every vendor building perimeter hardware is fighting the same fundamental tension between administrative convenience (a reachable management interface, a feature that just works out of the box) and attack surface. Palo Alto isn’t worse at this than Cisco or Fortinet. It’s the same industry-wide problem showing up on a slightly different logo every few weeks, and treating each disclosure as an isolated vendor failure rather than a category means missing the actual lesson.

What to actually do about it

If you’re running PA-Series or VM-Series firewalls, patch CVE-2026-0310 on the same timeline you would have used in May for CVE-2026-0300, not a relaxed one, because “not yet exploited” is a snapshot, not a forecast. Confirm your management interfaces aren’t reachable from the internet or any network you don’t fully trust, and if you administer them remotely, put a jump box in front rather than exposing the interface directly, which is Palo Alto’s own recommendation and good practice regardless of vendor. And if you’re running Captive Portal specifically, don’t assume May’s patch closed the book on that feature being worth a second look; a feature that produced one root-RCE is worth auditing for whether it’s even still needed.

More broadly, if any part of your estate treats “no known exploitation yet” as a reason to deprioritize a highest-urgency advisory, this pair of CVEs is the argument against that habit. CVE-2026-0300 went from disclosure to KEV to a three-day remediation deadline in under a week because it was already being used. CVE-2026-0310 hasn’t been, as far as Palo Alto knows, but it’s the same bug class on the same platform with a broader default attack surface. Patch on the advisory’s urgency rating, not on whether Unit 42 has published a threat brief yet.