Most firewall advisories arrive already exploited. This one did not, and that is the window.
On 9 September Palo Alto Networks published CVE-2026-0310, a buffer overflow in the way PAN-OS processes XML. An unauthenticated attacker who can reach the management web interface or a dataplane interface can send crafted XML and, on PA-Series hardware, execute code as root. There is no workaround. No special configuration is required to be affected. And, unusually for a firewall bug of this class in 2026, nobody is known to be exploiting it.
If you run PA-Series firewalls or Panorama and the upgrade is still sitting in next quarter's change calendar, this article is about you.
WHAT ACTUALLY HAPPENED
The flaw was found internally by Palo Alto Networks. It is an out-of-bounds write, CWE-787: XML content larger than a fixed-size buffer overwrites adjacent memory during processing. No credentials and no user interaction are needed, only network reachability to an interface that parses the XML.
What an attacker gets depends on the platform.
On PA-Series physical firewalls, arbitrary code execution with root privileges. Palo Alto scores this case CVSS-B 9.2.
On VM-Series, a denial of service, scored CVSS-B 8.7. Losing a virtual firewall still means losing every flow that crosses it.
On Prisma Access and Cloud NGFW, the risk is lower because exploitation requires authenticated access, scored CVSS-B 7.5. Cloud NGFW is updated automatically by Palo Alto; Prisma Access has fixed releases on its 10.2, 11.2 and 12.1 trains.
Panorama, the central management platform, is also listed as impacted.
Fixes exist on every supported train: PAN-OS 12.2.3, 12.1.10, 11.2.13-h2, 11.1.16-h2 and 10.2.18-h10, plus hotfixes for older maintenance releases, such as 11.1.7-h10 or 10.2.13-h24. The fixed-version table in the advisory is long, so check the exact hotfix for the build you run, not just the train.
At the time of writing, Palo Alto is not aware of malicious exploitation, and no public proof of concept has been reported.
READING THE SCORES CORRECTLY
Two numbers circulate for this bug, and the gap between them is where many patch decisions go wrong.
CVSS-B 9.2 is the base score: what the vulnerability allows. CVSS-BT 7.2 is the base score adjusted for threat, and the main input that pulls it down is exploit maturity, currently "unreported". The attack complexity, rated high, is already counted inside the 9.2.
In other words, the 7.2 does not say the bug is less dangerous. It says nobody has been seen using it yet. That number will move the day exploitation is reported, and on that day it will move all the way back up, with no new patch to wait for.
A vulnerability management process that sorts by CVSS-BT, or that treats "not in KEV" as "not urgent", will put this bug below dozens of lower-impact findings. Palo Alto itself set the urgency field of the PA-Series vector to red.
WHY THE DATAPLANE DETAIL MATTERS
After every serious PAN-OS bug of recent years, the advice has been the same: never expose the management interface to the internet, restrict it to a dedicated jump host. It is good advice, and it applies here too. Organisations that followed it after the management-interface bugs of 2024 and 2025 have a smaller attack surface today.
But this advisory names the dataplane interfaces as well. The dataplane is the part of the firewall that handles the traffic it protects, so it is reachable by design from the networks it sits between. The advisory does not detail which dataplane services hand XML to the vulnerable code. Until that is clear, treat every dataplane interface that can be reached from an untrusted network as in scope, and do not assume your management lockdown closes the issue.
Then think about what root means on that box. A PA-Series firewall enforces your segmentation, terminates your VPN tunnels, often decrypts TLS for inspection and holds credentials for directory and logging integrations. Code running as root on it can read all of that, change it, and do so from the one device whose traffic nobody questions. It is not one compromised host. It is every policy the firewall enforces.
THE SEPTEMBER PATTERN
The context makes the quiet around CVE-2026-0310 look temporary.
In September 2026, CISA added exploited vulnerabilities in network and security equipment from Cisco, Citrix, Fortinet, F5, Check Point and MikroTik to its Known Exploited Vulnerabilities catalog. Several of them are exactly the class of bug discussed here: unauthenticated, pre-authentication, on the edge.
The timelines are what matter. Attackers began compromising MikroTik routers through the MikroTrick chain on 2 September, a day before the vendor shipped fixes. F5 published its BIG-IP APM advisory on 22 September after it had already observed exploitation, and CISA gave federal agencies three days. Citrix NetScaler's pair of remote code execution flaws were exploited as zero-days before a fix existed.
Palo Alto has been on the same list before. In February 2025, CVE-2025-0108, an authentication bypass in the PAN-OS management web interface, was being exploited within days of disclosure, after researchers published how the patch worked. The window between "fixed" and "used" is not measured in quarters any more.
WHY "NOT EXPLOITED YET" IS A DEADLINE
Every fix is also a blueprint. Once fixed builds are available, anyone with access to both versions can compare them and locate the changed code. For a memory-corruption bug in a parser, that comparison points almost directly at the vulnerable function. In 2026 this patch diffing is increasingly assisted by AI tools, which keeps shortening the time from advisory to working exploit.
The high attack complexity will slow down opportunists who wait for a public script. It does not slow down well-funded teams, including state-backed groups that have spent years specialising in firewalls, VPN gateways and edge devices precisely because those devices rarely run endpoint detection and are trusted by everything behind them.
So the right reading of "no known exploitation" is not reassurance. It is the best position you will have with this bug: a fix is available, the vendor is not aware of attacks, and your change window is still yours to choose. The day the status changes, the same upgrade becomes an emergency performed under pressure, followed by a compromise assessment you could have avoided.
WHAT TO DO NOW
UPGRADE PA-SERIES AND PANORAMA FIRST — they are the root-RCE and central-management cases; book the window now instead of waiting for a KEV entry to force it.
MATCH THE EXACT FIXED BUILD — fleets are rarely on a single release; map every firewall and Panorama instance to the specific fixed version or hotfix for its maintenance release in the advisory table.
DO NOT FORGET VM-SERIES — a denial of service on a virtual firewall in the cloud or the data centre is an outage for every workload behind it; schedule those upgrades in the same campaign.
LOCK DOWN THE MANAGEMENT PLANE — management interface reachable only from dedicated jump hosts on an isolated admin segment, never from the internet and never from user VLANs; it reduces exposure even though it does not remove the dataplane path.
REVIEW DATAPLANE EXPOSURE — list which interfaces face the internet or other untrusted zones and which services are enabled on them, and remove any interface management profile or service that does not need to be there.
WATCH THE FIREWALL ITSELF — alert on unexpected reboots, crashes of management-plane or dataplane processes, configuration changes outside change windows and outbound connections initiated by the firewall; if you are not upgrading this week, look back over the logs since early September.
THE UNCOMFORTABLE PART
Most organisations only move fast on a firewall bug once it has a KEV entry, a CISA deadline and a headline. That habit worked when exploitation took months. In September 2026 it meant patching after the attackers had already arrived.
CVE-2026-0310 offers the rare opposite: a critical, unauthenticated, root-level bug with a fix available and no known attacks. That is not a reason to wait. It is the cheapest moment this vulnerability will ever give you.
So ask the question before someone else answers it for you. How many of your PA-Series firewalls are still waiting for a maintenance window, and what would it take to run that window this week instead of after the first KEV entry?