PAN-OS CVE-2026-0322: there is no single patch, there are twenty

On 14 October Palo Alto Networks published the advisory for CVE-2026-0322: a code injection flaw in the PAN-OS management interface that allows code execution as root. The same day it entered CISA's catalogue of exploited vulnerabilities with a 17 October deadline for federal agencies, and with a field that does not make the news: "forensicTriage": "Yes". The deadline is not only about patching; the required action includes the forensic triage requirements of directive BOD 26-04.

So far, an ordinary Wednesday in this industry. What changes the actual work starts when you open the advisory looking for the patch, because there is not one. There are twenty fixed versions, spread across five live PAN-OS branches. Six of them in the 11.1 branch alone. And the one that applies to you depends on a number somebody else probably chose years ago.

The count

Twenty. And the split is not arbitrary: each branch keeps several maintenance trains running in parallel, and the vendor fixes on the train you are on, rather than moving you to the next one. A young branch like 12.2 has one train and therefore one fixed version. A veteran, widely deployed branch like 11.1 has six live trains, and therefore six different patches for exactly the same flaw.

The practical consequence is unglamorous: before patching, you read the inventory version by version, including the box nobody counts. Eleven days ago we covered something similar in eight products and nineteen versions in a single advisory, but there the count came from eight different products. Here it comes from a single one, with five branches and several trains running inside each, which is a different kind of problem: knowing which products you have does not solve it, only knowing which train each one is on.

What the advisory says, and what it does not

CVE-2026-0322 is classified as code injection (CWE-94) and scores 8.6 on CVSS 4.0. That 8.6 is the result of two opposing forces inside the same vector: PR:H — high privileges required — pulls it down, and E:A — exploitation already observed — pushes it up. In practice the attacker needs a valid, privileged credential and network access to the management interface. With both, they run code as root on the appliance.

It affects PA-Series, VM-Series and Panorama (virtual and M-Series). It does not affect Cloud NGFW or Prisma Access, in any version. On exploitation, the advisory is terse and therefore credible: "Very limited exploitation has been observed targeting the Palo Alto Networks management interface". It does not claim a mass campaign. It says it has already happened.

"Requires authentication" is not the comfort it looks like

When an advisory requires credentials, the committee's reflex is to relax. We do the opposite exercise: count how many privileged accounts exist today on the management plane of an average firewall. There is the administrator's. The integrator's, from when it was installed. The previous maintenance provider's, which nobody revoked because on migration day there were more urgent things. The API key of the monitoring tool. And some service account with no clear owner, created for an integration that no longer exists.

That list is what turns a PR:H into a problem. And the route by which those credentials change hands is rarely technical: it tends to be a call to the service desk, something we covered in who verifies, on the other end of the phone, that it is you. Reviewing who can get into the management interface today costs one afternoon and needs no change window.

Panorama is the piece that hurts most

In the affected list, Panorama comes last and should come first. A compromised firewall is a compromised firewall; the manager from which policies are pushed to the whole estate is something else. Whoever controls that does not need to attack the boxes one by one: it is enough to change what the boxes will apply on the next commit.

And it is worth remembering something we already wrote when it was another vendor's turn: patching stops the entry, it does not undo the visit. If the management plane was exposed and there was access, what the attacker took — rules, objects, addressing, the entire map of your network — is still theirs after the patch. We covered it in full in patching closes the door but does not erase what the attacker already took.

The advisory says there is no workaround

Worth quoting as it stands, because it gets skipped: "No known workarounds exist for this issue". What the advisory does offer is partial coverage through inspection: enabling Threat IDs 510046 and 510047.

That partial coverage comes with small print, worth reading before you tick it off: it requires four things first — routing management traffic through a data-plane port, replacing the management interface certificate, decrypting inbound management traffic and enabling threat inspection — and even then the advisory warns that coverage is limited.

Building that on a Friday afternoon is a project with risks of its own, not a quick fix. What is left sits on the same page and it is the usual thing: "The risk is highest when you allow access to the management interface from external IP addresses on the internet". Restricting management access to a set of trusted internal addresses or to a single jump host lowers the risk without touching a single traffic rule, and it still works for the next management-interface CVE, which will come.

What we would do this week

1. List versions, not vendors. Every PA-Series, every VM-Series and every Panorama, with its exact version. The inventory that helps here has a version column, not a brand column.
2. Find your train in the advisory and copy the number from there. You can trust the table above today; the advisory, always. If your branch is no longer supported, the jump is not a patch: it is a planned upgrade.
3. Check exposure before version. If the management interface answers from the internet, that gets fixed today and does not wait for the change window.
4. Review privileged accounts on the management plane and remove the ones that should not be there: former providers, dead integrations, ownerless API keys.
5. Look back through the logs. This is not our idea: the KEV entry flags "forensicTriage": "Yes" and the required action points to CISA's forensic triage requirements. The advisory publishes three addresses associated with the observed activity: 66.42.72.14, 208.83.239.114 and 149.248.47.234. Searching for them in management access logs is cheap; finding them changes the whole plan.

When this is not an emergency

If your management interface only answers from a separate administration network, the privileged accounts fit on one hand and you review them, this patch fits your normal change window. The three-day rush belongs to CISA and its agencies, and on top of that the third day falls on a Saturday, a calendar quirk we already wrote about in three days to patch and the third lands on a Saturday. Saying otherwise would sell better and would be false: a badly chosen perimeter firewall reboot buys you guaranteed downtime minutes, and what the advisory describes today is very limited exploitation.

What we do, and what we do not claim

We are not resellers of any security platform, and this is not a recommendation to switch vendors: a management interface CVE is not an argument against a product, it is a reminder of where the risk lives. We run our own network and we design, deploy and maintain infrastructure, with NetBox as the source of truth for inventory: that is where the version column lives, and today it decides how long this takes. The part of cybersecurity that actually moves the needle is almost never the patch of the day; it is that the list exists, is current, and somebody is obliged to read it when an advisory lands. Nor do we claim how many appliances are exposed in Spain, because we have not measured it.

Sources (checked 16 Oct 2026): the vulnerability description, the CWE-94 classification, the 8.6 CVSS 4.0 score with PR:H, the list of affected products (PA-Series, VM-Series and Panorama virtual and M-Series) and unaffected ones (Cloud NGFW and Prisma Access), the twenty fixed versions across five branches, the "Upgrade to a supported fixed version" for unsupported branches, the sentence "Very limited exploitation has been observed targeting the Palo Alto Networks management interface", the three associated IP addresses, Threat IDs 510046 and 510047 with their four requirements and limited coverage, and the sentence "The risk is highest when you allow access to the management interface from external IP addresses on the internet", all come from the official Palo Alto Networks advisory for CVE-2026-0322. The publication date (14 October 2026), the addition to CISA's Known Exploited Vulnerabilities catalogue and the 17 October deadline for federal agencies come from Help Net Security (15 Oct 2026). Ours, and we bound it: the count of twenty and its reading as the number of live maintenance trains, the priority order that puts Panorama first, the privileged-account list, the comparison between inspection-based mitigation and an address list, the five steps and the "when this is not an emergency".