Hunt PAN-OS CVE-2026-0322: Three Attacker IPs and Management Plane Logs

Palo Alto Networks published CVE-2026-0322 on October 14: authenticated code injection in the PAN-OS management interface that runs as root. CVSS 8.6. Exploit maturity: attacked. CISA KEV the same day, due October 17. The advisory even handed defenders three IPs tied to limited exploit attempts. This lab session turns those IOCs into greps you can paste into a SIEM after you lock the management plane like you meant it.

What you are hunting

CVE-2026-0322 is CWE-94 code injection in the PAN-OS management interface. An attacker who already has high privileges on that interface and network reachability can execute arbitrary code as root on PA-Series, VM-Series, and Panorama (virtual and M-Series). Cloud NGFW and Prisma Access are not impacted. Palo Alto’s wording: “Very limited exploitation has been observed targeting the Palo Alto Networks management interface.” Limited is not zero. KEV is not a participation trophy.

• Published attacker IPs: 66.42.72.14, 208.83.239.114, 149.248.47.234
• Threat Prevention (limited): Threat IDs 510046 and 510047 from Applications and Threats content 9159-10287 and later (needs SSL decryption and specific MGT routing; see advisory)
• No workaround other than patching and restricting management access

Step 1: string and IP hunt

printf '%s\n' 66.42.72.14 208.83.239.114 149.248.47.234 | tee iocs.txt
grep -E '66\.42\.72\.14|208\.83\.239\.114|149\.248\.47\.234' panos_mgmt_lab.log

In the lab you should see allow and deny rows for those sources against a fake MGT address. On real gear, widen to GlobalProtect portals only if you are confused about architecture. This bug is about the management interface, not “VPN vibes.” Pull firewall, proxy, and jump-host logs that front the MGT IP.

Step 2: Threat ID and frequency

awk -F'src=' '/src=/{split($2,a," "); print a[1]}' panos_mgmt_lab.log | sort | uniq -c | sort -rn
grep -E 'threat_id=51004[67]' panos_mgmt_lab.log

Threat Prevention coverage is explicitly limited. Palo Alto says variations may evade the signatures, and the Threat IDs only help if you route MGT traffic through a dataplane interface with decryption and threat profiles in the awkward way the advisory describes. Treat a Threat ID hit as a high-priority ticket. Treat a miss as “still patch.”

Step 3: build matrix reality check

Fixed trains (from the advisory product table, not vibes) include examples such as PAN-OS 12.2.4+, 12.1.4-h12 / 12.1.7-h8 / 12.1.10-h2, multiple 11.2 and 11.1 hotfixes, and 10.2 hotfixes through lines like 10.2.18-h12. The 11.2.16 line had an ETA of October 15 in the advisory. Unsupported older major versions: upgrade to a supported fixed release. Our lab script only hints at sample strings. Your change ticket should quote the advisory row for your exact minor train.

Fixed version cheat sheet (verify against the live advisory)

• PAN-OS 12.2: upgrade to 12.2.4 or later
• PAN-OS 12.1: 12.1.4-h12, 12.1.7-h8, or 12.1.10-h2 (depending on minor)
• PAN-OS 11.2 / 11.1 / 10.2: use the hotfix rows in the Palo Alto table; do not invent a build
• Cloud NGFW / Prisma Access: no action for this CVE

What “authenticated” changes about your panic

This is not a pre-auth internet free-for-all like some of the VPN disasters of the last two years. Privileges Required is high. That means the attacker already has admin-class access to the management plane, or they bought/phished/stuffed their way there. The correct emotional response is still urgent, but the control that matters most after patching is: who can talk to MGT at all.

Palo Alto’s own severity note says risk is highest when management is exposed to the internet, and they publish a second CVSS assuming adjacent/jump-box access. If your MGT interface still has a public A record, congratulations on volunteering as a case study.

SIEM detections to drop tonight

• Any connection to PAN-OS management IPs from 66.42.72.14, 208.83.239.114, 149.248.47.234 (and your threat-intel updates of that set)
• Threat logs for IDs 510046 / 510047 after content 9159-10287+
• Successful admin logins to MGT from unfamiliar ASNs in the last 30 days
• Config commits or operational API calls (type=op, type=config) outside change windows
• CMDB check: PAN-OS builds still below the fixed hotfix for each train

What to actually do on real gear

1. Patch per the advisory matrix. Schedule the reboot. Document the build string after.
2. Restrict MGT to jump hosts / out-of-band management networks. Kill internet exposure.
3. Rotate admin credentials and API keys that touched MGT during the exploitation window described in your logs.
4. If IOC IPs or suspicious admin sessions hit, open IR. Root on a firewall is not a “monitor and see” finding.
5. Federal scope: October 17 KEV due date. BOD 26-04 forensic triage language applies when you are in that bucket.

Sloth take

Edge firewalls with public management interfaces are how the industry cosplays as serious. An authenticated root RCE on that plane is the encore. Patch the hotfix. Grep the IPs. Put MGT behind a jump box that requires a second factor and a second thought. Your board slide that says “Next-Gen Firewall” should not include a footnote that says “admin GUI on the internet, lol.”

Want a boring, careful look at firewall management exposure? Book Dark Edge Consulting.

Mapping MGT exposure before you grep anything

Pull the management IP list from Panorama device inventory, DHCP reservations, and your firewall’s own show interface management style output (syntax varies by train; use the CLI reference for your build). For each MGT address, answer: internet-reachable, VPN-only, jump-host-only, or flat internal. Internet-reachable MGT with admin passwords from 2019 is how “limited exploitation” becomes your week.

Then map who holds admin-class credentials. CVE-2026-0322 needs high privileges. Credential hygiene and management-plane network hygiene are the same incident. Patching a firewall whose admin password is Pal0Alto! and whose MGT ACL is any is interior decorating.

Jump-box pattern that is not theater

• MGT ACL permits only the jump host subnet
• Jump host requires phishing-resistant MFA and is not also your intern’s browsing VM
• Admin sessions are recorded; API keys are short-lived and inventoried
• Certificate for inbound management traffic is not the factory default museum piece
• If you enable the limited Threat Prevention coverage path, you accept the decryption and dataplane hairpin complexity from the advisory instead of pretending a signature alone saved you

Lab cleanup and false positive notes

Our synthetic log plants the three advisory IPs next to innocent RFC 5737 documentation addresses so you can see ranking work. In production, Cloudflare or hosting ranges can be noisy. Do not page the planet for a single packet without auth context. Do page for authenticated admin sessions from those IPs, repeated API ops, or Threat ID hits correlated with config commits.

Also remember: absence of the three IPs does not mean absence of exploitation. Palo Alto published a seed set tied to limited activity. Attackers rotate. Your durable controls are patch level and MGT exposure, not a forever blocklist of three dotted quads.

IR branch if you confirm a hit

1. Isolate MGT access to break-glass jump hosts only
2. Capture tech support files / device state per Palo Alto guidance before mass reboot-as-coping
3. Assume root: review admin users, auth profiles, outbound rules recently committed, and any unusual scheduled jobs
4. Rotate all admin and API credentials; review whether Panorama pushed malicious config elsewhere
5. Rebuild from known-good where trust is gone; “clean the webshell and hope” is not a firewall strategy

Sources

• Palo Alto Networks Security Advisory CVE-2026-0322 (published 2026-10-14)
• CISA KEV catalog entry for CVE-2026-0322 (added 2026-10-14, due 2026-10-17)
• CISA alert: four KEV additions on October 14, 2026