CVE-2022-0028 is a reflected amplification denial-of-service vulnerability in Palo Alto Networks PAN-OS. CISA added it to the Known Exploited Vulnerabilities catalogue on 22 August 2022, which means attackers have used it in real attacks. 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.
What this vulnerability means in PAN-OS
CVE-2022-0028 is a reflected amplification denial-of-service flaw, which matters because a misconfigured URL filtering policy can let a remote attacker turn normal traffic handling into a source of oversized response traffic. In practice, the danger is less about code execution and more about making the firewall or the network path participate in service disruption.
This kind of weakness is especially relevant in perimeter products because they sit close to public traffic and are expected to absorb hostile or malformed requests without becoming an amplifier. When that expectation fails, the vulnerable device can be used to flood targets indirectly, often with less attacker bandwidth than a direct flood would require.
Why reflected amplification attacks are dangerous
Reflected amplification attacks abuse a third-party system to generate more traffic than the attacker sends. That makes them efficient, hard to attribute quickly, and capable of overwhelming bandwidth, connection state, or upstream infrastructure before defenders can react.
A reflected attack path also changes the defensive problem: the immediate symptom may appear far from the attacker, while the exploited product is only one step in the abuse chain. For the reader, the key point is that the vulnerable PAN-OS component is not just exposed to disruption, it can become part of the disruption mechanism itself. The general shape of these attacks is well covered in DDoS Protection Guide.
Because the issue is tied to a policy misconfiguration, organisations should treat configuration review as part of exposure analysis, not just software patching. A device can remain operationally risky even when only a narrow traffic path is affected.
How organisations assess exposure and reduce blast radius
Exposure assessment starts with knowing where PAN-OS is deployed, which internet-facing services depend on it, and whether URL filtering policies are configured in a way that could trigger the vulnerable behaviour. Vendor advisories and the CISA Known Exploited Vulnerabilities catalogue should be used for authoritative patch and mitigation details rather than guessing from secondary summaries.
When a fix cannot be applied immediately, the practical focus is on constraining reachability and reducing the chance that the affected service path can be abused at scale. That usually means tightening exposure, limiting the affected policy surface, and making sure upstream capacity can absorb short bursts of hostile traffic.
For vulnerability prioritisation, this type of issue should be treated as more than a theoretical flaw because it is in the KEV catalogue and has been used in real attacks. A disciplined process for asset scope, KEV-driven prioritisation and remediation tracking is described in the Vulnerability Management Guide.
Detection, verification, and post-incident review
Detection should focus on signs that the firewall or adjacent network path is generating abnormal reflected traffic, suffering unusual load, or behaving inconsistently with the configured policy. Teams should also look for evidence that traffic spikes align with the vulnerable service path rather than with unrelated volumetric noise.
After patching or mitigation, review whether the device was abused before the fix was applied, because a DDoS condition can mask other activity and may leave limited but important telemetry behind. The post-change question is not only whether the vulnerability is fixed, but whether the environment showed signs of being used as an amplifier.
For the broader defensive pattern, the right operational reference is a DDoS response runbook and continuous verification of whether the device is still able to participate in amplified traffic. Teams that need a concise control-oriented reference can use the DDoS Protection Guide alongside vendor guidance and KEV status checks.
Risk and Threat Considerations
This vulnerability matters because an internet-reachable edge device can be coerced into reflecting and amplifying traffic, turning an ordinary configuration weakness into a denial-of-service path against third parties or the organisation itself. The abuse pattern is attractive to attackers because it can produce disruptive traffic with comparatively little attacker bandwidth.
Failure mechanism: A URL filtering policy misconfiguration allows requests to trigger reflected and amplified TCP responses, which increases the traffic load beyond what the attacker directly sends.
Impact: Services can become unavailable, upstream links can saturate, and the affected system may be used as part of a broader distributed denial-of-service event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-5 — Denial of Service Protection | Directly addresses reflected DoS exposure from an edge network device. |
| CM-6 — Configuration Settings | The issue is triggered by a URL filtering policy misconfiguration. | |
| SI-2 — Flaw Remediation | A KEV-listed vulnerability requires timely remediation and verification. | |
| Recommendation — Harden edge services with SC-5 to limit amplification and absorb hostile traffic. Use CM-6 to baseline and review PAN-OS policy settings that could enable amplification. Apply SI-2 to track, remediate and verify the vulnerable PAN-OS configuration promptly. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Covers secure management of network devices and their exposed services. |
| Recommendation — Manage the PAN-OS edge posture under CIS-12 and restrict unnecessary exposure paths. | ||
| NIST CSF 2.0 | PR.PS-05 — Asset Management | The response depends on identifying where the vulnerable PAN-OS instance is deployed. |
| Recommendation — Map every PAN-OS asset and prioritize exposed instances for remediation. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a configuration-plus-exposure problem, not just a patching ticket. The operational question is whether the vulnerable policy path is reachable, actively used, and capable of amplifying traffic under realistic conditions.
What to watch for: Validate affected policy paths, confirm vendor remediation guidance, and watch for traffic patterns that suggest the device is being used as a reflector or amplifier. If immediate patching is not possible, reduce exposure and limit the conditions under which the policy can be triggered.
Practitioner takeaway: For KEV-listed DDoS flaws, speed matters, but so does confirming that the specific configuration path is actually closed.