CVE-2026-0322: what one valid credential still buys on a PAN-OS management interface

CISA added CVE-2026-0322 to the Known Exploited Vulnerabilities catalog on 14 October and set a federal remediation due date of 17 October. Palo Alto Networks rated the urgency highest on its advisory ¹². The flaw is code injection in the PAN-OS management interface, tracked as CWE-94, and an attacker who holds a credential and can reach that interface runs code as root on the firewall ². The advisory reports very limited exploitation against management interfaces and names three IP addresses tied to the attempts ².

One credential is the whole gate

Privileges Required is High in the vendor’s vector, and that field is the reason this kind of record lands below an unauthenticated finding in a queue ². PR:H here means one working login on a management interface. A local administrator account. A service account that a monitoring tool signs in with, on a password nobody has rotated since the tool went in. A stale account somebody kept because disabling it looked like a bigger change than leaving it.

The attacker supplies the credential, and the flaw supplies root access. That trade changes the question I ask first. For an unauthenticated bug I ask whether the service answers from the internet. For this one I ask who can sign in, and how many people and scripts hold those accounts. Management interfaces collect credentials the way mailboxes collect old subscriptions, and the list stays unaudited until an advisory names the interface.

Palo Alto Networks states that no special configuration is required for the flaw to be reachable, so nothing has to be enabled to be in scope ². If the management interface answers at the attacker’s network position, the appliance is exposed.

Reachability, accounts, and a signature that needs help

The vendor’s first mitigation is to restrict management access to trusted internal addresses, or to a jump box that is the only host allowed to reach the interface ². That control changes who can attempt the attack, and it works before an upgrade window opens. I ask to see the address list, then the account inventory behind the interface, including the accounts that automation uses, which hold long-lived credentials and sit outside anyone’s daily attention.

Threat Prevention gives limited coverage instead of a fix. Threat IDs 510046 and 510047, from Applications and Threats content version 9159-10287 and later, catch known attack patterns, and the advisory warns that variations may exist which those signatures do not detect ². Those signatures only help once the firewall can inspect the traffic, which means routing management traffic through a dataplane port with SSL decryption enabled, and the advisory states that no workarounds exist ².

The three addresses in the advisory, 66.42.72.14, 208.83.239.114 and 149.248.47.234, go into the management login review I run, because a source address sitting in my own authentication logs tells me more than a description of exploitation does ².

Fixed builds exist on every supported branch: 12.2.4 on 12.2, hotfixes across 12.1, 11.2, 11.1 and 10.2, and anything older and unsupported moves to a supported fixed release ². The advisory credits Suraj Siddharudh, an internal reporter, for the discovery, and the record still reached the KEV catalog with active exploitation attached to it ²¹.

Two scores on the same record

Palo Alto Networks scores CVE-2026-0322 at 8.6 under CVSS v4.0, and NVD carries a v3.1 primary score of 7.2 with the vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H ²³. Both numbers describe the same flaw. The v4.0 vector reports Exploit Maturity as Attacked and Automatable as No, and the coordinator entry in the NVD record reads exploitation active, automatable no, technical impact total ²³.

The 1.4 point gap comes out of the arithmetic inside two metric versions. FIRST’s v4.0 specification tells consumers to enrich base metrics with threat and environmental values for their own environment, and to feed the result into a remediation decision that also weighs factors outside CVSS ⁴. A queue that sorts on a single number places this record wherever that number puts it, so two tools holding different metric versions put the same flaw in different places. The advisory prints its base score and its base plus threat score as the same 8.6, because the base score already assumes the worst case for Exploit Maturity, and the vector carries that value as E:A ²⁴.

The v3.1 score arrived after the advisory. Palo Alto Networks published on 14 October, and NVD last modified the record on 15 October with the 7.2 attached, so the advisory’s number had a day on its own ²³. I note which number a comparison is using when I line this CVE up against the rest of a patch cycle, and I pull the vector when a vendor score and an NVD score disagree.

What I relay, and in what order

My part in a case like this is assessment and relay; deployment is automated, and the teams that own the appliance carry the upgrade. The order I put in the relay does not follow the patch date. Exposure comes first: which interface answers, from where, and whether the answering addresses match the documented ones. Accounts come second: stale logins, shared logins, automation credentials, and authentication records that show sign-ins from addresses the appliance should never have talked to.

CISA’s alert ties these listings to BOD 26-04, which requires federal agencies to prioritize KEV entries on publicly exposed assets that grant total control after exploitation, and sets expectations for checking whether an attacker had access before the patch went in ⁵. That second expectation is the one a post-auth finding loses. Root on a firewall puts the configuration, and every credential the configuration holds, inside the scope of the review, so the upgrade closes the vulnerability while the credential check tells me whether anything used it.

The patch closes the hole. The credential behind the management plane is the part I still want an answer on after it lands.