Palo Alto Networks has patched CVE-2026-0322, a code injection flaw in the PAN-OS management interface that lets an attacker run code as root on the firewall. The company says it is aware of limited exploitation against customer firewalls and has published indicators of compromise.

CISA added it to the exploited catalogue on 14 October with a 17 October deadline — three days, which is as short as CISA sets. We read that from the feed directly.

Affected: PA-Series and VM-Series firewalls and Panorama. Cloud NGFW and Prisma Access are not affected. Fixes exist across the 10.2, 11.1, 11.2, 12.1 and 12.2 branches, with a build for 11.2.16 expected today.

It needs credentials, and that is the interesting part

The CVSS vector lists privileges required as high: an attacker must already have valid credentials for the management interface and network access to it. The score is 8.6 rather than a 9-point-something for exactly that reason.

It is tempting to read that as a mitigating factor. It is more useful to read it as a question: who can reach your management interface, and with whose credentials?

Because the requirement only binds if the interface is hard to reach. On a firewall whose management plane is bound to an internal address, reachable from a jump host, with administrators on phishing-resistant authentication, "requires credentials" is a real barrier. On a firewall whose management interface answers from the internet — which is a configuration that exists in large numbers, repeatedly, across every vendor in this category — it is a formality. Credentials are the most widely traded commodity in the criminal economy.

Palo Alto's own mitigation advice says the same thing in vendor language: restrict management interface access to trusted internal addresses. There is no workaround. Threat Prevention signatures give partial coverage against known patterns, which is not the same as protection.

Two Palo Alto flaws, and what connects them is not a chain

We wrote four days ago about CVE-2026-0257, an authentication bypass in GlobalProtect that forges a session cookie and has been in CISA's catalogue since May, still being used by ransomware crews five months on.

It is tempting to put the two together into a chain: use the first to get in, the second to get root. We are not going to, because the pieces do not obviously fit. CVE-2026-0257 produces an authorised VPN session as a user. CVE-2026-0322 needs credentials for the management interface, which is a separate authentication surface. Nobody has demonstrated one leading to the other, and inventing the link would be the kind of thing this site complains about when others do it.

What is true without the chain is simpler. The same product line has two separately exploited flaws in active use this month, one needing nothing and one needing credentials, and the defensive answer to both is about where the interfaces are reachable from rather than about either bug.

Why these interfaces end up reachable

"Restrict the management interface to trusted internal addresses" is correct and it is also the advice that has been given after every firewall flaw for a decade. It is worth asking why it keeps needing to be given.

Some of it is remote administration: the people who manage the device are not in the building, and the management plane became the path of least resistance before anyone wrote down a better one. Some of it is managed service providers running fleets across customers who have no shared private network. Some of it is VM-Series instances in cloud accounts, where "internal" is a boundary somebody had to define rather than a wall that already existed.

And some of it is simple risk asymmetry. Locking down a management plane is a change that can lock the administrator out of the device that controls their own network path, at which point recovery means physical access. The failure mode of leaving it open is theoretical until a day like today. The failure mode of getting the lockdown wrong is immediate.

That is not an argument for leaving it open. It is why the fix is a planned change with a tested rollback, not a checkbox, and why it keeps being deferred.

What to do

  • Patch to a fixed release for your branch. Check the vendor advisory for the exact build; the branch coverage is wide and the 11.2 build landed last.
  • Then answer the reachability question honestly. If the management interface is reachable from anything other than a defined administrative network, that is the finding, and it outlives this CVE.
  • Review the published indicators. Palo Alto has released IP addresses associated with the observed activity.
  • Rotate management-interface credentials after patching. A flaw that requires credentials is a flaw whose exploitation implies somebody had them.
  • Treat Panorama with the same urgency as the firewalls. It is in scope and it manages the rest.

What is not established

  • Who is exploiting it. No attribution has been offered.
  • How attackers are obtaining the credentials the flaw requires.
  • How many devices are affected. "Limited exploitation" is the vendor's characterisation, without a figure.
  • Whether a public proof of concept exists. One aggregator records no available exploit, which contradicts the vendor and CISA and appears to be automated rather than researched.
  • Whether this and the GlobalProtect bypass have been used against the same targets.