Is CVE-2026-0322 (Palo Alto Networks PAN-OS Code Injection) being exploited in the wild?

What “being exploited in the wild” means for this PAN-OS CVE

For a CVE like this, “in the wild” is not a vague concern level. It means there is credible evidence that attackers are actively using the vulnerability outside the lab, which is why CISA places it in the Known Exploited Vulnerabilities catalogue. For defenders, that changes the question from “is this serious?” to “can we prove exposure and stop further abuse fast enough?”

Because the flaw is in a network-facing firewall platform, the first practical concern is not the abstract code injection mechanism, but whether your deployment is reachable, managed, and still running the affected software path. If the device sits on a critical perimeter, any delay in verification can translate into direct exposure of the trust boundary it protects.

For edge appliances, the security value is often concentrated in the management plane, authentication posture, logging quality, and patch discipline. NHIMG’s Edge Device Security Guide is useful here because it frames firewalls and similar appliances as high-value control points where management exposure and logging minimums matter as much as the patch itself.

What to check before you assume you are affected

Start by confirming whether the firewall is actually in scope for the vendor advisory and whether it is internet reachable, remotely manageable, or exposed through any administrative path that an authenticated attacker could reach. Do not rely on asset inventory alone if you also have virtualised, lab, partner-managed, or redeployed devices that may not be tracked cleanly.

Next, verify whether the device has the vulnerable product line, whether the management plane is restricted, and whether local logs show suspicious logins, unusual configuration changes, or command execution signals around the date CISA added the CVE to KEV. For actively exploited edge devices, the absence of a confirmed alert is not strong evidence of safety unless the logging and retention are good enough to support that conclusion.

When a CVE is already in KEV, CISA’s Known Exploited Vulnerabilities Catalog should be treated as a prioritisation trigger, not just another reference. Pair it with the NIST National Vulnerability Database and the CVE Program record to confirm the identifier, product mapping, and vendor remediation path without relying on secondary summaries.

Response priorities when patching or mitigation is delayed

If you cannot patch immediately, the goal is to reduce the attacker’s practical reach before they can turn initial access into broader firewall control. That usually means tightening management exposure, restricting source IPs, reviewing administrative accounts and sessions, and preserving logs before any reboot or upgrade removes evidence.

For a code injection issue on a firewall, contingency actions should be treated as temporary risk reduction, not a substitute for remediation. If the appliance is customer-facing or sits between sensitive zones, assume an attacker may be able to leverage the device itself as a foothold for privileged execution, then move laterally into adjacent trusted segments.

NHIMG’s Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide both support the operational side of this decision: triage KEV items first, shorten the time to mitigation, and use verification after change rather than assuming the vendor fix alone resolves exposure. If the device is part of an edge fleet, use the same discipline you would use for any internet-facing appliance with administrative reach.

Risk and Threat Considerations

The material risk is that an actively exploited firewall flaw can collapse a control boundary that other systems assume is trustworthy. Once an attacker reaches a firewall with elevated code execution, they may be able to tamper with policy, intercept traffic, stage persistence, or use the appliance as a pivot point into internal networks.

Failure mechanism: Authenticated code injection on a perimeter device can turn a management or access path into privileged system execution, which is especially dangerous when the appliance guards multiple network zones.

Impact: The likely consequence is loss of trust in the firewall itself, plus possible exposure of internal traffic, credentials, policy changes, or downstream compromise of systems that depended on that boundary.

Practitioner Guidance

What to verify: Confirm the exact PAN-OS deployment, management exposure, and log retention before trusting any “not affected” conclusion. If the device cannot produce usable administrative and system logs for the relevant period, treat that as an investigation gap, not as clean evidence.

Decision rule: If the firewall is internet reachable or protects high-value segments, prioritise remediation ahead of lower-criticality infrastructure even when no incident is yet confirmed. If patching must wait, reduce exposure first and then re-check for compromise indicators after the change window.

Practitioner takeaway: For KEV-listed edge-device flaws, the main decision is whether you can still trust the boundary, not whether the CVE sounds severe enough on paper.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2026-0322 (Palo Alto Networks PAN-OS Code Injection)?
• CVE-2026-0322 (Palo Alto Networks PAN-OS Code Injection)
• Is CVE-2017-15944 (Palo Alto Networks PAN-OS Remote Code Execution) being exploited in the wild?
• Is CVE-2024-9474 (Palo Alto Networks PAN-OS Management Interface OS Command Injection) being exploited in the wild?