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

> CVE-2026-0322 lets an authenticated attacker who can reach the PAN-OS management interface run code as root on PA-Series and VM-Series firewalls and Panorama. Palo Alto Networks has seen very limited exploitation, there is no workaround, and CISA gave federal agencies three days. Here are the fixed releases, a version checker built from the CVE record, and what to review after you patch.

- URL: https://firewallsync.com/posts/pan-os-cve-2026-0322-management-interface-rce-patch-and-hunt/
- Site: FirewallSync (https://firewallsync.com/)
- Topic: Security Operations
- Tags: vulnerability management, incident response, firewalls, code injection
- Published: 2026-10-26
- Author: John Marshall

## Key takeaways

- CVE-2026-0322 is a code injection flaw (CWE-94) in the PAN-OS management interface. An authenticated attacker with network access to that interface can run arbitrary code as root. It affects PAN-OS on PA-Series and VM-Series firewalls and on Panorama; Cloud NGFW and Prisma Access are not affected.
- Palo Alto Networks says 'very limited exploitation' has been observed. CISA added it to the KEV catalog on October 14, 2026, with a federal due date of October 17 and the forensic triage flag set.
- There is no workaround. The fixes are hotfix releases on every supported branch, from 10.2 to 12.2, and the right one depends on which maintenance release you run. Check yours against the table below or the script in this article.
- Authentication is not much of a barrier if the interface is reachable. Restrict management access to a dedicated management network or jump host, keep it off the internet and off any interface that carries GlobalProtect, and require MFA for administrators who can make changes.
- Patch, then review: preserve logs first, then look at administrator logins, new or changed admin accounts and configuration commits since early October, starting with management access from addresses outside your management network.



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.

| Branch | If you run | Upgrade to |
|---|---|---|
| 12.2 | 12.2.0 through 12.2.3 | 12.2.4 or later |
| 12.1 | 12.1.8 through 12.1.10-h* | 12.1.10-h2 or later |
| | 12.1.5 through 12.1.7-h* | 12.1.7-h8, or 12.1.10-h2 or later |
| | 12.1.2 through 12.1.4-h* | 12.1.4-h12, or 12.1.10-h2 or later |
| 11.2 | 11.2.14 through 11.2.15 | 11.2.16 or later |
| | 11.2.11 through 11.2.13-h* | 11.2.13-h3, or 11.2.16 or later |
| | 11.2.8 through 11.2.10-h* | 11.2.10-h15, or 11.2.16 or later |
| | 11.2.5 through 11.2.7-h* | 11.2.7-h21, or 11.2.16 or later |
| | 11.2.0 through 11.2.4-h* | 11.2.4-h22, or 11.2.16 or later |
| 11.1 | 11.1.14 through 11.1.16-h* | 11.1.16-h3 or later |
| | 11.1.11 through 11.1.13-h* | 11.1.13-h15, or 11.1.16-h3 or later |
| | 11.1.8 through 11.1.10-h* | 11.1.10-h35, or 11.1.16-h3 or later |
| | 11.1.7 through 11.1.7-h* | 11.1.7-h11, or 11.1.16-h3 or later |
| | 11.1.5 through 11.1.6-h* | 11.1.6-h39, or 11.1.16-h3 or later |
| | 11.1.0 through 11.1.4-h* | 11.1.4-h37, or 11.1.16-h3 or later |
| 10.2 | 10.2.17 through 10.2.18-h* | 10.2.18-h12 or later |
| | 10.2.14 through 10.2.16-h* | 10.2.16-h11, or 10.2.18-h12 or later |
| | 10.2.11 through 10.2.13-h* | 10.2.13-h26, or 10.2.18-h12 or later |
| | 10.2.8 through 10.2.10-h* | 10.2.10-h41, or 10.2.18-h12 or later |
| | 10.2.0 through 10.2.7-h* | 10.2.7-h38, or 10.2.18-h12 or later |

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](https://security.paloaltonetworks.com/CVE-2026-0322) 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.

```python
#!/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:

```text
$ 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:

| Scenario | Score | Attack vector | Privileges required |
|---|---|---|---|
| Management interface reachable from external IP addresses on the internet | 8.6 High | Network | High |
| Access restricted to a jump box that is the only system allowed to reach the interface | 8.5 High | Adjacent | High |

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](/posts/how-to-read-a-cvss-v4-0-vector-string-metric-by-metric-with-real-cve-records/) 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](/posts/cisa-bod-26-04-explained-kev-deadlines-forensic-triage-and-what-private-teams-can-borrow/) and its forensic triage requirements.
- **CISA SSVC (in the CVE record):** Exploitation "active", Automatable "no", Technical Impact "total". Our [explainer on Vulnrichment SSVC values](/posts/cisa-vulnrichment-how-to-read-ssvc-values-in-a-cve-record-and-turn-them-into-a-patch-decision/) 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.

| Question | Where to look |
|---|---|
| Who logged in to management, from where? | System and authentication logs: administrator logins from source addresses outside your management network or jump hosts, and logins at unusual times |
| Did anyone connect from the reported addresses? | Firewall traffic logs and any upstream logs for `66.42.72.14`, `208.83.239.114` and `149.248.47.234` |
| Were admin accounts added or changed? | Configuration logs and the current administrator list against your expected set |
| What changed in the configuration? | Configuration logs and commit history: new NAT or security rules, new management profiles, changed authentication profiles, new certificates |
| Is the device talking somewhere new? | Outbound connections from the management address and the firewall itself to destinations it does not normally reach |

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](/posts/logging-for-incidents-not-for-dashboards/) 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

| Important claim | Source | Status |
|---|---|---|
| Authenticated RCE as root via the management interface; PA-Series, VM-Series and Panorama affected; Cloud NGFW and Prisma Access not | [CVE-2026-0322 record (Palo Alto Networks CNA)](https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/0xxx/CVE-2026-0322.json) | Verified |
| Fixed-release table, no workaround, Threat IDs 510046/510047 and their conditions, no special configuration needed | Same record, solutions, workarounds and configurations | Verified |
| CWE-94; CVSS v4.0 8.6 and 8.5 with the vectors shown; internal discovery | Same record | Verified |
| "Very limited exploitation has been observed" | Same record, exploits | Verified |
| KEV added 2026-10-14, due 2026-10-17, ransomware Unknown, forensic triage Yes | [CISA KEV catalog data](https://github.com/cisagov/kev-data) | Verified |
| SSVC active / no / total | CISA ADP container in the CVE record | Verified |
| 16 Palo Alto Networks KEV entries; CVE-2024-0012, CVE-2024-9474, CVE-2026-0300, CVE-2026-0257 details | CISA KEV catalog data; CVE records for CVE-2026-0300 and CVE-2026-0257 | Verified |
| Three IP addresses linked to the activity | [BleepingComputer](https://bleepingcomputer.com/news/security/palo-alto-networks-warns-of-pan-os-rce-flaw-exploited-in-attacks), [The Hacker News](https://thehackernews.com/2026/10/palo-alto-networks-patches-pan-os.html) | Qualified: press reports |
| Analyst comment on credential hygiene | [CSO Online](https://www.csoonline.com/article/4235787/attackers-exploit-palo-alto-pan-os-flaw-for-root-access-as-cisa-orders-three-day-fix.html) | Verified (attributed) |
| Management access guidance quoted | [PAN-OS admin guide: securing administrative access](https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/getting-started/best-practices-for-securing-administrative-access); [management interface settings](https://docs.paloaltonetworks.com/ngfw/administration/set-up-firewalls/device-setup/configure-the-management-interface-settings) | Verified; the first page is from the 9.1 guide |
| Version checker output | Our run of the script above | Verified (computed) |

## Frequently asked questions

### Is CVE-2026-0322 exploitable without a login?

Not on its own. Palo Alto Networks describes it as an authenticated remote code execution flaw, and its CVSS v4.0 vectors rate the privileges required as high. The practical risk is stolen or reused administrator credentials, or an interface that other weaknesses expose. Treat it as urgent if your management interface is reachable from anywhere other than a management network.

### Which PAN-OS versions fix CVE-2026-0322?

The newest fixes per branch are 12.2.4, 12.1.10-h2, 11.2.16, 11.1.16-h3 and 10.2.18-h12. Older maintenance releases have their own hotfixes, such as 11.1.6-h39 or 10.2.13-h26. The full table is in the article.

### Are Cloud NGFW and Prisma Access affected?

No. Palo Alto Networks lists Cloud NGFW and Prisma Access as not impacted. Panorama is affected, both the virtual appliance and M-Series.

### Is there a workaround for CVE-2026-0322?

No. Palo Alto Networks says no known workarounds exist. Threat Prevention Threat IDs 510046 and 510047 give limited coverage, but only if management traffic is routed through a dataplane interface and decrypted so the firewall can inspect it. Restricting who can reach the management interface reduces the risk; upgrading removes it.


Image credit: Photo by [smallbox](https://unsplash.com/photos/pCnsAvfbetw) on Unsplash