Is CVE-2022-0028 (Palo Alto Networks PAN-OS Reflected Amplification Denial-of-Service) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 18, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-0028 to its Known Exploited Vulnerabilities catalogue on 22 August 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A Palo Alto Networks PAN-OS URL filtering policy misconfiguration could allow a network-based attacker to conduct reflected and amplified TCP denial-of-service (RDoS) attacks.

How to interpret active exploitation for CVE-2022-0028

CISA’s KEV listing is the practical signal that matters here: for a publicly reachable PAN-OS exposure, you should treat the vulnerability as actively used in real attacks, not as a theoretical denial-of-service issue. The immediate question is whether any internet-facing Palo Alto Networks PAN-OS deployment still exposes the affected URL filtering path, because that is what determines whether the attack is reachable.

For a reflected and amplified TCP denial-of-service issue, the operational impact is usually service degradation rather than data theft. The control objective is to confirm whether your edge footprint includes the vulnerable condition, then determine whether upstream filtering, rate limiting, or vendor mitigation is already reducing the attack surface.

Because CISA linked the issue to active exploitation, the safest assumption is that opportunistic scanning and repeat attempts are already part of the threat picture. That makes this less about abstract vulnerability management and more about exposure reduction, service resilience, and fast confirmation of whether the relevant traffic path exists at all. The Edge Device Security Guide is useful here because the subject is an internet-facing network appliance, where management exposure, firmware hygiene, and logging quality directly affect containment and investigation.

What defenders should verify before relying on a patch window

First verify whether the relevant PAN-OS instances are internet-facing and whether URL filtering is enabled in the configuration path tied to the advisory. Then check whether any security controls upstream of the appliance can absorb an RDoS event, because a patch alone does not help if the device remains directly reachable and saturated before mitigation can take effect.

When patching must wait, treat this as a bandwidth and state-exhaustion problem, not a generic application bug. Temporary protections may include tighter ingress filtering, scrubbing, upstream rate controls, and reducing unnecessary exposure to the affected service path. If the device is handling critical perimeter traffic, validate failover behaviour before the event, not during it.

For prioritisation, use the fact of active exploitation to move this ahead of routine backlog work. The Zero-Day and Exploited Vulnerabilities Guide fits this decision point because KEV-listed issues are handled on a different timeline from ordinary CVEs. The DDoS Protection Guide also applies directly, since the most useful mitigation decisions here are about scrubbing, rate limiting, and runbook readiness rather than only software replacement.

What evidence matters after exposure is confirmed

If a PAN-OS instance was exposed during the KEV period, review traffic and availability data for signs of repeated bursts, unusual protocol patterns, or service instability affecting the firewall or adjacent network path. Even when the flaw is not used to drop payloads or steal credentials, denial-of-service attempts can still create partial outages, noise in monitoring, and pressure on response capacity.

Check whether the appliance or surrounding network showed a step change in drops, resets, connection churn, or degraded throughput around the date CISA added the CVE. If you have logs from the relevant window, preserve them before making major configuration changes so you can distinguish attack activity from normal load or unrelated instability.

The CISA Known Exploited Vulnerabilities Catalog should remain the authoritative operational trigger for remediation timing, while the CVE Program remains the record of the vulnerability identifier itself. For a broad process view, the Vulnerability Management Guide is the best internal reference because it covers KEV prioritisation, verification, and exception handling for exploited flaws.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation demands rapid exposure verification and prioritised remediation.
	CIS-12 — Network Infrastructure Management	The issue affects an internet-facing network appliance and its traffic path.
Recommendation — Prioritise and remediate the exposed PAN-OS flaw through continuous vulnerability management. Harden and monitor the edge appliance and its network controls to reduce DoS exposure.
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events	Active exploitation makes traffic and availability monitoring central to detecting attack attempts.
	RS.MA-01 — Incidents are contained and mitigated	RDoS exploitation requires immediate containment and traffic mitigation actions.
	PR.PS-03 — Configuration management is performed	The advisory hinges on a misconfiguration in PAN-OS URL filtering.
Recommendation — Monitor edge traffic and service health for indicators of exploitation and disruption. Contain the attack path and apply mitigation controls to preserve service availability. Review and correct the appliance configuration that creates the exploitable condition.

Practitioner Guidance

What to prioritise: Treat exposed internet-facing PAN-OS assets as the first priority, then confirm whether URL filtering and the relevant traffic path are actually present. If the device is externally reachable and cannot be upgraded immediately, move straight to compensating controls and monitoring rather than waiting for a perfect maintenance window.

What to verify: Verify both configuration and reachability. A vulnerability that exists in a product line is not the same as a vulnerability that is exploitable in your environment unless the affected path is deployed and exposed.

Decision rule: If the firewall is directly exposed and you cannot remove or patch the condition quickly, assume the system is already a target and shorten your response cycle to containment, traffic protection, and post-event validation.

Practitioner takeaway: For KEV-listed denial-of-service flaws, the practical decision is not whether exploitation is possible, but how quickly you can prove exposure, reduce reachability, and keep the edge service available while you remediate.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org