Table of contents
15
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: CVE-2026-0322 is a root-level code injection in the PAN-OS management interface, found internally by a Palo Alto researcher, already under limited active exploitation from three identified IPs, and added to CISA’s KEV catalog on October 14, 2026 with a three-day remediation deadline.
- Palo Alto classifies it as requiring an authenticated attacker, but NVD and the vendor disagree on the number: 7.2 under CVSS 3.1, 8.6 under the vendor’s own CVSS 4.0 scoring.
- Three IP addresses are tied to the limited exploitation Palo Alto has observed: 66.42.72.14, 208.83.239.114, and 149.248.47.234.
- No public proof-of-concept exists as of this writing, and no threat actor or campaign has been named by Palo Alto or by any outlet we checked.
- This is the third PAN-OS vulnerability CISA has added to its KEV catalog in 2026 alone, a pattern we confirmed ourselves against the live catalog rather than assumed.
- Two independent security researchers quoted by CSOonline raised a question Palo Alto’s own advisory doesn’t address: once an attacker has root on a firewall, can you actually trust anything that device reports about itself afterward?
Palo Alto’s advisory for CVE-2026-0322 calls this “an authenticated attacker with network access.” That phrasing tends to make people relax a little, the way “requires authentication” generally does. It shouldn’t here, and two independent researchers interviewed after the disclosure made exactly that point.
CVE-2026-0322 sits in the PAN-OS management interface, the control-plane service that administers PA-Series and VM-Series firewalls and Panorama. Palo Alto’s own advisory describes it as letting “an authenticated attacker with network access execute arbitrary code with root privileges on the firewall.” Cloud NGFW and Prisma Access are explicitly not affected; this is an on-premises and self-managed appliance problem.
CVE-2026-0322 was discovered internally, not by an outside researcher or a bug bounty submission. Palo Alto credits Suraj Siddharudh, whom BleepingComputer identifies as a senior principal product security researcher at the company, with finding and reporting it before it was found in the wild, though the advisory itself also confirms limited exploitation was already happening by the time of disclosure.
CVE-2026-0322 is CWE-94, improper control of code generation, classic code injection. The advisory states plainly: “No special configuration is required to be affected by this issue.” Risk goes up considerably, Palo Alto says, specifically when the management interface is reachable from the internet rather than restricted to trusted internal addresses, which is the same guidance Palo Alto has been repeating since at least its 2024 management-interface incidents.
NVD scores CVE-2026-0322 at 7.2 under CVSS 3.1. Palo Alto’s own advisory for CVE-2026-0322 scores it at 8.6 under CVSS 4.0. Both numbers are correct for their respective scales, and the gap is worth understanding rather than picking whichever one sounds scarier.
CVSS 4.0 adds a field CVSS 3.1 doesn’t have: exploit maturity. Palo Alto’s vector string includes E:A, meaning Attacked, a direct acknowledgment baked into the score itself that this is being exploited right now, not a theoretical risk. CVSS 3.1 has no equivalent field to capture that. So the higher 4.0 number isn’t vendor inflation; it’s the newer framework literally scoring “this is happening” as a severity multiplier that the older one can’t express.
The field both scores share and both mark identically is PR:H, privileges required: High. That’s the detail worth sitting with.
Here’s the gap between how this reads in a headline and what the scoring actually says. PR:H isn’t “any logged-in user.” It’s an attacker who already holds high-level privileges on the device before they ever touch this bug. In plain terms: this isn’t the entry point. Something else got them there first, a stolen admin credential, a reused password, an internet-exposed management interface they’d already compromised, or a prior incident nobody closed out.
Yih Khai Wong, an analyst at IDC quoted by CSOonline, made almost exactly this point: the likely path in is “weak management-access practices, such as stolen or reused admin credentials, internet-exposed management interfaces, or an earlier compromise,” not some novel bypass of PAN-OS authentication itself. Wong also pushed back on the instinct to solve this purely with network segmentation: a jump box “only limits access and doesn’t reduce damage from an intruder with valid credentials,” so credential hygiene and detecting misuse after a valid login matter at least as much as restricting who can reach the interface at all.
That reframes the whole bug. CVE-2026-0322 isn’t really a “how did they get in” story. It’s a “what happens once they’re already in with real credentials” story, and that’s a harder problem than patching.
Palo Alto’s own language about CVE-2026-0322’s exploitation is specific: “Very limited exploitation has been observed targeting the Palo Alto Networks management interface.” Three IP addresses are associated with that activity, named directly in the advisory: 66.42.72.14, 208.83.239.114, and 149.248.47.234.
Beyond that, the public record is thin, and we’re not going to pad it out with speculation. No threat actor or campaign name has been attached to this by Palo Alto, by CISA, or by any outlet we checked, including BleepingComputer, which says it asked Palo Alto directly about timing and scope and did not get specifics in response. No public proof-of-concept exists as of this writing either, which matters for your own risk calculus: broad opportunistic scanning against this specific bug hasn’t started yet, as far as anyone has published.
We pulled CISA’s live KEV catalog JSON directly, checking where CVE-2026-0322 fits, rather than repeat a number from another article. Palo Alto has had 16 entries in the KEV catalog in total, across every year CISA has tracked exploited vulnerabilities. Three of those sixteen were added in 2026 alone: CVE-2026-0300 in May, CVE-2026-0257 later in May, and now CVE-2026-0322 in October.
Three KEV entries against one vendor’s flagship OS inside a single calendar year is a real cadence, not noise. It doesn’t tell you this specific bug is worse than the two before it. It does tell you PAN-OS firewalls have been a live target all year, which should factor into how aggressively you patch the next Palo Alto advisory that lands in your inbox, not just this one.
| Train | Affected | Upgrade to |
|---|---|---|
| PAN-OS 12.2 | 12.2.0 – 12.2.3 | 12.2.4 or later |
| PAN-OS 12.1 | 12.1.2 – 12.1.10-h1 (three sub-ranges) | 12.1.4-h12, 12.1.7-h8, or 12.1.10-h2, per your branch |
| PAN-OS 11.2 | 11.2.0 – 11.2.15 (five sub-ranges) | 11.2.4-h22, 11.2.7-h21, 11.2.10-h15, 11.2.13-h3, or 11.2.16 |
| PAN-OS 11.1 | 11.1.0 – 11.1.16-h2 (six sub-ranges) | 11.1.4-h37 through 11.1.16-h3, per your branch |
| PAN-OS 10.2 | 10.2.0 – 10.2.18-h11 (five sub-ranges) | 10.2.7-h38 through 10.2.18-h12, per your branch |
There is no workaround for CVE-2026-0322. Palo Alto says so directly. Customers with a Threat Prevention subscription can enable Threat IDs 510046 and 510047 for partial coverage, but that requires SSL decryption on inbound management traffic and Palo Alto’s own FAQ admits “variations may exist that cannot currently be detected.” Treat it as a stopgap, not a fix.
The practical first move for most environments: confirm your management interface isn’t reachable from the internet, regardless of what patch train you’re on, since that single configuration choice is what Palo Alto says determines whether this is a minor exposure or your highest-urgency ticket this week.
Vibhum Dubey, a researcher and red teamer quoted in the same CSOonline piece, raised the part of this story that a patch doesn’t resolve: if an attacker already had root on a firewall via CVE-2026-0322, what is that firewall’s own reporting actually worth afterward? His framing: an attacker with root control “undermines the device’s ability to enforce security,” which means the device itself becomes an unreliable witness to whether it’s clean.
Dubey’s recommended sequence for CVE-2026-0322 isn’t “patch, then move on.” It’s check every Panorama instance and every managed firewall, preserve evidence before you touch anything, and only then patch, because patching first can erase the very logs you’d need to confirm whether you were compromised in the first place. That ordering matters more than the patch itself if you have any reason to suspect your management interface has been reachable from somewhere it shouldn’t have been.
We’re not going to pretend a penetration test would have caught an internally-discovered zero-day before Palo Alto’s own security team found it. What we will say honestly: the entry point both independent analysts pointed to, weak credential hygiene and overexposed management interfaces, is exactly the surface our AI VAPT services are built to find before an attacker does, on infrastructure you’ve authorized us to test.
A pentest report tells you what was tested and what we found. It can’t tell you whether a specific device was already compromised before you engaged us, and it doesn’t replace the evidence-preservation and TAC-engagement steps Palo Alto and Dubey both recommend if you suspect this CVE was already used against you. XHack doesn’t store your session data; it stays on your own machine.
Yes, and specifically high-privilege authentication, per the PR:H field both NVD and Palo Alto assign it. That means an attacker needs to already hold elevated access, through a stolen credential, a reused password, or a prior compromise, before this bug becomes useful to them. It is not a bypass of PAN-OS login itself.
NVD uses CVSS 3.1 and scores it 7.2. Palo Alto scores it 8.6 using CVSS 4.0, a newer framework that includes an exploit-maturity field. Palo Alto’s vector marks that field E:A (Attacked), which pushes the 4.0 score higher because the framework itself accounts for confirmed active exploitation in a way 3.1 cannot.
Not as of this writing, based on every source we checked, including a dedicated review by SOC Prime. Palo Alto has confirmed limited, targeted exploitation from three specific IP addresses, which is a different and narrower situation than a public PoC enabling broad opportunistic scanning.
Treat the device as a candidate for compromise rather than assuming the patch alone clears it. Preserve logs and evidence before patching, review admin login history for anything unexplained, and consider engaging Palo Alto TAC if you find anything. Patching first can destroy the evidence you’d need to confirm whether you were already hit.
Three, as of this article: CVE-2026-0300 in May, CVE-2026-0257 later in May, and CVE-2026-0322 in October. We verified this directly against CISA’s live KEV catalog rather than citing a secondary count.
CVE-2026-0322 is a real, currently-exploited bug, but the number that should worry you more than its CVSS score is the “high privileges required” field everyone keeps glossing over as a mitigating factor. Two independent researchers read it the opposite way: if the entry point is already-valid high-privilege credentials, segmentation alone doesn’t save you, and a patched firewall isn’t automatically a trustworthy one.
Patch CVE-2026-0322 to the version for your branch, confirm your management interface isn’t internet-facing, and if there’s any chance it has been, do the evidence-preservation work before you touch the upgrade button, not after.
Categories
Related articles
