PAN-OS CVE-2026-0321 patch matrix: five branches, one deadline

Palo Alto Networks published CVE-2026-0321 on 14 October 2026 with a fix in each supported PAN-OS branch. The engineering work is not deciding whether to upgrade. It is choosing the right fixed release per device, because the record lists multiple hotfix entry points per branch.

What the record fixes, branch by branch

Branch	Affected below	Fixed releases named in the record
PAN-OS 10.2	10.2.18-h12	10.2.18-h12, 10.2.16-h11, 10.2.13-h26, 10.2.10-h41, 10.2.7-h38
PAN-OS 11.1	11.1.16-h3	11.1.16-h3, 11.1.13-h15, 11.1.10-h35, 11.1.7-h11, 11.1.6-h39, 11.1.4-h37
PAN-OS 11.2	11.2.16	11.2.16, 11.2.13-h3, 11.2.10-h15, 11.2.7-h21, 11.2.4-h22
PAN-OS 12.1	12.1.10-h2	12.1.10-h2, 12.1.7-h8, 12.1.4-h12
PAN-OS 12.2	12.2.4	12.2.4

The practical reading is that a fleet is rarely on one version line. Most estates have one branch on current hardware, one branch kept alive on older chassis, and a lab box nobody has spoken about since the last audit. Build the matrix from device inventory, not from memory.

Choosing between the newest fix and the nearest hotfix

The top release in each branch is the safest default when the device has upgrade room. A hotfix lower in the list exists for teams that cannot take a full maintenance-window jump, usually because of feature dependencies or a tightly controlled change calendar.
The trade-off is maintenance debt. Taking 10.2.7-h38 today leaves a device far behind 10.2.18-h12, and the next advisory will repeat this exercise with a shorter runway. Record the reason for choosing a lower hotfix in the change ticket, so the next engineer inherits a decision rather than a mystery.

Cloud NGFW and Panorama

The record marks Cloud NGFW and Panorama unaffected by CVE-2026-0321. Do not let that become a reason to skip the whole change. Panorama appears in the same October 2026 batch for a separate log-processing buffer overflow tracked as CVE-2026-0318, which is a different fix on a different schedule. Bundling them casually into one window is how teams create confusion about what was actually patched.

Verification after upgrade

Confirm the running version on each device rather than trusting the installer's success message. Check that the device left any maintenance state, that the dataplane is forwarding, and that HA peers agree on the running configuration. A firewall that reports the right version but sits in a degraded sync state has not finished upgrading.

Compensating controls during the gap

The record states no known workarounds. Threat Prevention subscribers can enable Threat ID 510038 once Applications and Threats content 9158-10284 or later is installed, with the caveat that the signature requires SSL Decryption. Teams without decryption should plan on zero inline coverage and lean on segmentation and traffic monitoring instead.
Segmentation earns its keep here. If a dataplane outage can be contained to a segment that carries no critical flows, the blast radius shrinks even though the bug remains. That is a reason to know which firewall carries which business service before the window opens.

Scheduling without pretending

Two schedules are honest. The first upgrades every internet-facing dataplane within a short, named window and accepts the operational cost. The second upgrades behind a documented risk acceptance with a hard end date and named owner.
The dishonest third option is an open-ended postponement justified by the MEDIUM score. With PR:N and VA:H, an unauthenticated attacker gets to choose when a firewall becomes unavailable, and repeated attempts can leave it in maintenance mode. Nothing about a 6.6 score makes that someone else's problem.

Exposure context, used carefully

A ZoomEye query for app="Palo Alto Networks" returned 22,599 matching assets at the time of writing, and a CVE-level filter for this identifier returned 0 because indexing had not caught up. Treat the first figure as a rough size of the product family on the internet and the second as a reminder that a fresh CVE has no footprint yet. Neither replaces a version check on your own estate.

Close-out checklist

Record the fixed release installed per device. Note any device that took a lower hotfix and why. Attach the verification output. Set the next review date before the ticket closes, because the October 2026 batch will not be the last one this quarter.