CVE-2026-0322 on PAN-OS: High Privileges Required, Root Delivered

Palo Alto Networks published the advisory for CVE-2026-0322 on October 14, 2026. It is a code injection flaw (CWE-94) in the PAN-OS management interface, and a successful attack runs arbitrary code as root on the firewall. The CVSS 4.0 score is 8.6, with the vector AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H. The exploit maturity field reads E:A, which means attacked, and Palo Alto says it has seen “very limited exploitation” against management interfaces. CISA has added the CVE to its Known Exploited Vulnerabilities catalog.

The part of that vector that matters most is PR:H. The attacker needs high-privilege credentials and network reach to the management interface. This is not an unauthenticated bug, and the advisory is clear about that. It is also why the score sits below the 9.2 I covered in CVE-2026-0310, which needed no credentials at all.

What is affected

PA-Series and VM-Series firewalls and Panorama (virtual and M-Series) on PAN-OS 10.2, 11.1, 11.2, 12.1 and 12.2 are affected. Cloud NGFW and Prisma Access are not. The advisory says no special configuration is needed for a vulnerable version to be exposed, so there is no optional feature to check for and switch off.

The fixes ship as per-branch hotfixes. The latest builds listed in the advisory are:

Branch	Fixed in
12.2	12.2.4
12.1	12.1.10-h2 (also 12.1.7-h8, 12.1.4-h12)
11.2	11.2.13-h3, or 11.2.16
11.1	11.1.16-h3
10.2	10.2.18-h12

Unsupported releases get no fix. Check the advisory for the exact hotfix that matches your maintenance train, and for whether 11.2.16 is available yet, because it was listed with a release ETA rather than a ship date.

What the advisory does not say

Palo Alto does not describe the root cause. There is no vulnerable parameter, no request format and no trigger condition in the advisory, and the three secondary write-ups I read add nothing there. The vulnerability was found internally and credited to a Palo Alto researcher, yet it is already being used against customers. I can’t tell you how that happened, and nobody has published an attribution or a post-exploitation account either.

So I am not going to guess at a mechanism. What the advisory does give you is the class, the privilege level, the exposure and three indicators of compromise:

• 66.42.72[.]14
• 208.83.239[.]114
• 149.248.47[.]234

Search your management-plane logs for those. Finding nothing does not clear a device, because the list comes from limited observed activity.

Why 8.6 undersells it

CVSS 4.0 says the attack needs high privileges, and that pulls the number down. That is a fair reading of the bug in isolation. It is a poor guide to what you should do with it.

First, the threat-adjusted score here equals the base score. In the CVE-2026-0310 post I pointed out that Palo Alto’s September advisory discounted a 9.2 base to a 7.2 threat score because nobody was exploiting it yet. This advisory has no such discount. The score is 8.6 on both sides because the exploitation already exists.

Second, this is the third PAN-OS root code-execution flaw of 2026. CVE-2026-0300 in May hit the Authentication Portal, and CVE-2026-0310 in September was an out-of-bounds write in XML processing. This one is in the management plane. The bugs are different, the privilege at the end is the same, and the pattern is the one I keep writing about for perimeter firewalls this year.

Third, PR:H is only reassuring if credentials stay private. The management interface is the one place where a stolen administrator login is worth the most. FortiBleed showed administrator password hashes being cracked offline at scale, and the same post covered CVE-2026-0257, where a forged GlobalProtect cookie replaced credentials entirely. From the outside, a credential failure and a code defect looked identical. I have no evidence that either was used against CVE-2026-0322. The point is only that a high-privilege requirement is a weaker barrier than the vector string suggests.

The management interface keeps being the target

This is not a Palo Alto problem alone. The same exposure shows up across vendors on this site this year:

• CVE-2026-25089 gave unauthenticated command injection in the FortiSandbox web interface.
• CVE-2026-70468 let an attacker register with FortiManager as any managed FortiGate.
• CVE-2026-20245 is the closest comparison. It is also an authenticated path to root, on Cisco Catalyst SD-WAN Manager, and it was exploited in a real intrusion before it was patched.

In each case the fix is a vendor patch, and in each case the exposure that decided who got hurt was reachability of the management plane.

What I would do

1. Patch first. There is no workaround. Move to the fixed hotfix for your branch on the same timeline you would use for an unauthenticated bug.
2. Restrict management access. Limit the management interface to trusted internal addresses or a single jump host. The advisory names this as the main risk reducer. The jump-host scenario scores 8.5 instead of 8.6, which tells you how little the vector changes when the attacker is already on an adjacent network. I wrote about the same discipline from the build-standard side in The Golden Template Part 1.
3. Treat the Threat IDs as partial. Threat IDs 510046 and 510047 (content version 9159-10287 or later) give limited coverage, but they only work if you decrypt inbound management traffic. Most estates don’t, so don’t count on them.
4. Check for signs of misuse. Look for management logins from unexpected addresses, administrator accounts that don’t normally touch the firewall, configuration changes with no change record, and unexpected outbound connections from the device. Search for the three addresses above.
5. Rotate administrator credentials if you can’t rule out compromise, after you have contained the device.

If your management interface is reachable from the internet, patching is the second thing to do. Closing that exposure is the first.

Sources: Palo Alto Networks advisory for CVE-2026-0322, SOC Prime analysis, Threataft write-up.