PAN-OS CVE-2026-0322: Patch the Management Interface RCE

CVE-2026-0322 is a code injection vulnerability in the management interface of Palo Alto Networks PAN-OS. An attacker who is authenticated and can reach that interface over the network can execute arbitrary code with root privileges on the firewall. It affects PA-Series and VM-Series firewalls and Panorama, there is no workaround, and Palo Alto Networks says it has observed “very limited exploitation”. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on October 14, 2026, and gave federal agencies until October 17 to act.

If you run PAN-OS, find your exact version, upgrade to the matching fixed release below, and use the upgrade window to check who can reach the management interface at all. Everything in this article comes from Palo Alto Networks’ CVE record and CISA’s KEV entry unless we say otherwise.

Are you affected?

You are affected if you run PAN-OS on a PA-Series or VM-Series firewall, or Panorama (virtual or M-Series), and your version is below the fixed release for its maintenance range. Palo Alto Networks says “no special configuration is required to be affected”. Cloud NGFW and Prisma Access are not impacted.

This is the solutions table from the CVE record as published on October 14, 2026. Two details are easy to miss. First, a hotfix only fixes its own maintenance release: 11.1.4-h37 is fixed, but 11.1.5 is not, because 11.1.5 sits in the next row with its own fix (11.1.6-h39). Second, the record’s affected range for 12.1 starts at 12.1.0, while the solutions table starts at 12.1.2; if you are on 12.1.0 or 12.1.1, move to 12.1.10-h2. Branches older than 10.2 are not listed; check the Palo Alto Networks advisory for their status.

Check a list of versions

With a fleet, a lookup beats reading the table by eye. This Python 3 script encodes the table above. We checked it against the record: its 20 in-line fixes are the same set as the 20 changes entries in the record’s affected data, and its per-branch upper bounds match the record’s lessThan values. We ran it on Python 3 with the versions shown.

#!/usr/bin/env python3
"""Check PAN-OS versions against the CVE-2026-0322 fix table (CVE record, 2026-10-14).
Usage: python3 check_0322.py 11.1.6-h20 10.2.18-h12 ..."""
import re, sys

# (first version in range, last minor in range, in-line fix, newest fix on the branch)
ROWS = [
    ("12.2.0", "12.2.3", "12.2.4", "12.2.4"),
    ("12.1.8", "12.1.10", "12.1.10-h2", "12.1.10-h2"),
    ("12.1.5", "12.1.7", "12.1.7-h8", "12.1.10-h2"),
    ("12.1.2", "12.1.4", "12.1.4-h12", "12.1.10-h2"),
    ("11.2.14", "11.2.15", "11.2.16", "11.2.16"),
    ("11.2.11", "11.2.13", "11.2.13-h3", "11.2.16"),
    ("11.2.8", "11.2.10", "11.2.10-h15", "11.2.16"),
    ("11.2.5", "11.2.7", "11.2.7-h21", "11.2.16"),
    ("11.2.0", "11.2.4", "11.2.4-h22", "11.2.16"),
    ("11.1.14", "11.1.16", "11.1.16-h3", "11.1.16-h3"),
    ("11.1.11", "11.1.13", "11.1.13-h15", "11.1.16-h3"),
    ("11.1.8", "11.1.10", "11.1.10-h35", "11.1.16-h3"),
    ("11.1.7", "11.1.7", "11.1.7-h11", "11.1.16-h3"),
    ("11.1.5", "11.1.6", "11.1.6-h39", "11.1.16-h3"),
    ("11.1.0", "11.1.4", "11.1.4-h37", "11.1.16-h3"),
    ("10.2.17", "10.2.18", "10.2.18-h12", "10.2.18-h12"),
    ("10.2.14", "10.2.16", "10.2.16-h11", "10.2.18-h12"),
    ("10.2.11", "10.2.13", "10.2.13-h26", "10.2.18-h12"),
    ("10.2.8", "10.2.10", "10.2.10-h41", "10.2.18-h12"),
    ("10.2.0", "10.2.7", "10.2.7-h38", "10.2.18-h12"),
]
# "lessThan" bound of each affected range in the record's affected[] data
LESS_THAN = {"12.2": "12.2.4", "12.1": "12.1.10-h2", "11.2": "11.2.16",
             "11.1": "11.1.16-h3", "10.2": "10.2.18-h12"}

def key(v):
    m = re.fullmatch(r"(\d+)\.(\d+)\.(\d+)(?:-h(\d+))?", v.strip())
    if not m:
        raise ValueError(f"unrecognised version: {v}")
    a, b, c, h = m.groups()
    return (int(a), int(b), int(c), int(h or 0))

def check(v):
    k = key(v)
    for start, last, fix, newest in ROWS:
        if key(start) <= k and k[:3] <= key(last)[:3]:
            if k >= key(fix):
                return f"{v}: fixed (in-line fix {fix})"
            return f"{v}: AFFECTED -> upgrade to {fix}" + ("" if fix == newest else f" or {newest}")
    branch = ".".join(map(str, k[:2]))
    if branch in LESS_THAN:
        if k >= key(LESS_THAN[branch]):
            return f"{v}: not affected (at or above {LESS_THAN[branch]})"
        return f"{v}: AFFECTED per the record, no row in the fix table -> {LESS_THAN[branch]}"
    return f"{v}: branch {branch} not listed in the CVE record (check the advisory)"

for v in sys.argv[1:]:
    print(check(v))

Sample output from our run:

$ python3 check_0322.py 11.1.6-h20 11.2.15 10.2.18-h12 12.1.1 10.1.14
11.1.6-h20: AFFECTED -> upgrade to 11.1.6-h39 or 11.1.16-h3
11.2.15: AFFECTED -> upgrade to 11.2.16
10.2.18-h12: fixed (in-line fix 10.2.18-h12)
12.1.1: AFFECTED per the record, no row in the fix table -> 12.1.10-h2
10.1.14: branch 10.1 not listed in the CVE record (check the advisory)

To get the input, read the running software version from each firewall and Panorama: on the CLI, show system info is the usual place to look (illustrative; we did not run it against a device). Feed those values to the script, and remember to include Panorama itself.

What the vulnerability does

The record classifies the flaw as CWE-94, improper control of generation of code (“code injection”). Its title is “Authenticated Remote Code Execution (RCE) in the Management Interface”, and the impact is code execution “with root privileges on the firewall”. Palo Alto Networks found it internally; the record credits an internal reporter and gives no technical detail of the vulnerable code path.

Palo Alto Networks publishes two CVSS v4.0 scores for two deployment scenarios:

Both vectors carry E:A (attacked), AU:N (not automatable) and U:Red. If you want to read the vector strings metric by metric, our guide to CVSS v4.0 vectors walks through each field.

The small gap between the two scores understates the operational difference. Restricting the interface to a jump box does not fix the bug, but it shrinks the set of places an attacker can attempt it from to one host you control and monitor.

“Authenticated” does not mean “safe to wait”

The CVSS vectors rate privileges required as High, so an attacker needs a valid management login. That is a real barrier, but not a high one when the interface is reachable. Speaking to CSO Online, IDC analyst Yih Khai Wong pointed to “weak management-access hygiene”: administrator credentials stolen through phishing or reuse, internet-reachable management interfaces, or an earlier compromise that left the attacker with valid logins.

PAN-OS management and edge services have a history here. CISA’s KEV catalog lists 16 Palo Alto Networks entries, including two management-interface flaws added on the same day in November 2024: CVE-2024-0012, an authentication bypass, and CVE-2024-9474, an OS command injection. In 2026 alone, CVE-2026-0322 is the third PAN-OS entry, after CVE-2026-0300 (an unauthenticated buffer overflow in the User-ID Authentication Portal, added May 6) and CVE-2026-0257 (a GlobalProtect authentication bypass, added May 29, which CISA marks as known to be used in ransomware campaigns). None of those records links them to CVE-2026-0322. The point is simpler: if your management access depends on nobody having a valid password, it is weaker than it looks.

Exploitation status

What the primary records say:

• Palo Alto Networks: “Very limited exploitation has been observed targeting the Palo Alto Networks management interface.” The record’s initial publication time is October 14, 2026, 16:00 UTC.
• CISA KEV: added October 14, 2026; due date October 17; known ransomware campaign use “Unknown”; forensic triage flag “Yes”. The required action points to BOD 26-04 and its forensic triage requirements.
• CISA SSVC (in the CVE record): Exploitation “active”, Automatable “no”, Technical Impact “total”. Our explainer on Vulnrichment SSVC values covers how to turn those into a patch decision.

What is reported but we could not confirm at the source: BleepingComputer reported that Palo Alto Networks shared three IP addresses linked to the activity, 66.42.72[.]14, 208.83.239[.]114 and 149.248.47[.]234. The Hacker News lists the same three as “assessed to be linked to the exploit attempts”. We did not read them on the advisory page itself, so treat them as reported indicators, and check the advisory for the current list. Neither outlet describes what attackers did after exploitation, and Palo Alto Networks has not said who is behind it or when it began.

What to do now

1. Upgrade to the fixed release for your maintenance range, firewalls and Panorama both. There is no workaround.
2. Preserve evidence before you upgrade if the management interface was reachable from anywhere you do not fully control. Export system, configuration and authentication logs, and take a tech support file, so the upgrade does not become the only record of the device’s state.
3. Restrict who can reach the management interface. Palo Alto Networks’ administrative access guidance says: “Do not enable access to your management interface from the internet or from other untrusted zones”, “Isolate the management interface on a dedicated management VLAN” and “Restrict the IP addresses that are permitted to access the management interface”. On the firewall this is the Permitted IP Addresses list on the management interface (Device > Setup > Interfaces > Management in the PAN-OS admin guide). An empty list allows access from any IP address.
4. Check dataplane interfaces too. If you manage the firewall through an interface management profile on a data port, restrict it the same way. The guidance is explicit that a profile allowing HTTP, HTTPS, Telnet or SSH must not be attached to an interface where a GlobalProtect portal or gateway is configured, because that exposes management to the internet.
5. Tighten administrator accounts. One account per person, the default admin password changed, and MFA through external authentication for administrators with change privileges. Rotate credentials for any administrator who logged in from outside the management network recently.
6. Use the Threat IDs only as a stopgap. Threat IDs 510046 and 510047 (Applications and Threats content 9159-10287 and later) offer what Palo Alto Networks calls limited coverage. They only work if management traffic is routed through a dataplane port with a management profile, its certificate is replaced, inbound management traffic is decrypted, and threat prevention is applied to it.

What to review after patching

Upgrading closes the hole; it does not tell you whether someone used it. Root code execution on a firewall means an attacker could have changed configuration, added accounts, or used the device as a foothold. Scope the review from the earliest date you think the interface was exposed, and at least from early October 2026.

As illustrative starting points in the PAN-OS CLI, show admins all lists administrators and their sessions, and show log system and show log config read the system and configuration logs. Check the CLI reference for your release for filters and exact syntax; we did not run these against a device.

If you find activity you cannot explain, treat the device as compromised rather than just patched: rebuild from a known-good configuration, rotate every credential and key the firewall holds (administrator passwords, API keys, certificates, VPN and directory service secrets), and involve Palo Alto Networks support. Our incident logging guide covers what to keep while you do.

Limits of this article

We did not test the vulnerability or run the CLI commands on a PAN-OS device. The fixed-release table and checker come from the CVE record as published on October 14, 2026; Palo Alto Networks can update the advisory, so check it before you finalise a change. The three IP addresses come from press reports, not from our reading of the advisory. Palo Alto Networks has not published technical details of the flaw or of the exploitation it observed.

Sources and verification

Vulnerability ManagementIncident ResponseFirewallsCode Injection