CISA’s required action for CVE-2022-0028 is to apply updates per vendor instructions. In practice, find every instance of Palo Alto Networks PAN-OS in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What patching CVE-2022-0028 means in practice
CVE-2022-0028 is handled as a perimeter appliance remediation problem, not just a software update task. The immediate job is to inventory every Palo Alto Networks PAN-OS instance, confirm which ones are exposed or reachable in ways that matter, and apply the vendor update or mitigation path that CISA directs. If you cannot remediate quickly, reduce exposure by removing internet access or taking the device out of service.
For internet-facing appliances, patching only closes the condition on paper. You still need to confirm whether management, VPN, or other reachable services were exposed to the reflected amplification pattern, because that determines whether the box was just vulnerable or actually usable as an attack surface. The operational question is whether the appliance can still be reached in a way that lets the flaw be triggered.
Use the vendor advisory and the CISA KEV catalog as the authoritative source for the exact update and mitigation path, then treat every affected deployment as a candidate for emergency maintenance. A reflected amplification denial-of-service issue is especially relevant on edge devices because even a short window of exposure can be enough to create service degradation, traffic flooding, or availability loss.
What to do if patching has to wait
If the fix cannot be applied immediately, the safest interim move is to eliminate the attack path rather than hope the device stays untouched. For PAN-OS on a public network, that usually means tightening exposure to the minimum required interfaces, placing it behind a control that can absorb or block abusive traffic, or removing it from service until the update is in place.
When a device must stay online, mitigation should focus on reducing reachable surface, not on informal monitoring alone. That means checking whether the vulnerable service is externally accessible, whether it must remain so, and whether traffic controls, upstream filtering, or temporary isolation can be used to prevent abuse while the maintenance window is prepared. The Edge Device Security Guide is useful here because it frames patching, logging, management exposure, and end-of-life handling as one operational problem for perimeter appliances.
Do not treat “mitigated” as a permanent state unless the exposure really changed. For reflected and amplified denial-of-service issues, partial controls can reduce blast radius, but they do not erase the underlying weakness if the vulnerable service remains reachable from untrusted networks.
How to check for earlier exploitation and remediate the aftermath
After patching, review logs for signs of earlier exploitation because CISA ties this flaw to known exploitation in the wild. Look for traffic spikes, repeated requests against the exposed service, unexplained availability issues, or other patterns consistent with a reflected denial-of-service event rather than ordinary load.
For appliance issues like this, the evidence is often operational rather than forensic in the narrow sense. You are trying to answer whether the device was only vulnerable, or whether someone already used it to create service degradation or as part of a broader attack campaign. The DDoS Protection Guide is relevant because it aligns the response with volumetric, protocol, and reflection-based attack patterns rather than generic incident handling.
If logs are incomplete, treat the gap itself as a finding. Edge appliances often have the weakest visibility exactly where attackers want to hit them, so missing telemetry should increase caution, not reduce it. Where the device participates in authentication, VPN, or administrative access paths, also confirm that no adjacent secrets or sessions were exposed during the attack window.
Risk and Threat Considerations
Reflected amplification flaws on perimeter devices are dangerous because they can be abused quickly, at scale, and with little warning. The same exposure that allows denial-of-service traffic to be reflected can also hide the attacker’s origin, making the event look like ordinary congestion until service quality drops.
Failure mechanism: An attacker sends crafted traffic to the vulnerable PAN-OS service, the device reflects or amplifies it toward a target, and the resulting flood consumes bandwidth or appliance resources until availability degrades.
Impact: Public services can become slow or unreachable, upstream links can be saturated, and the appliance may need emergency isolation or outage-inducing maintenance before normal service can resume.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | PAN-OS patching and exposure reduction are configuration-control actions. |
| DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | Reviewing logs for earlier exploitation depends on network and service monitoring. | |
| Recommendation — Apply configuration management to remove or constrain vulnerable PAN-OS exposure. Monitor appliance traffic and logs for signs of reflected attack activity. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The issue requires asset discovery, remediation, and verification of exposure closure. |
| CIS-8 — Audit Log Management | Post-patch review relies on logs to detect prior abuse or exploitation. | |
| Recommendation — Inventory PAN-OS assets and remediate or isolate vulnerable instances promptly. Retain and review appliance logs for evidence of pre-patch exploitation. | ||
| MITRE ATT&CK | T1498 — Network Denial of Service | The CVE is a reflected amplification denial-of-service condition. |
| Recommendation — Map observed traffic patterns to denial-of-service activity and tune detections accordingly. | ||
Practitioner Guidance
What to prioritise: Patch first on any PAN-OS instance that is internet-facing or supports critical remote access. If you have multiple appliances, triage by exposure and business impact rather than by general vulnerability score.
What to verify: Confirm the device is no longer reachable from untrusted networks in the vulnerable path, then verify logging is sufficient to show whether the flaw was exercised before remediation. If the logs cannot support that judgment, preserve the device state and escalate for deeper review.
Decision rule: If the vendor fix cannot be deployed promptly, prefer isolation or removal from service over a temporary acceptance of exposure. For this class of flaw, “watch and wait” is usually a weaker decision than reducing attack surface immediately.
Practitioner takeaway: For reflected amplification issues on edge appliances, the real question is not whether a patch exists, but whether the vulnerable path is still exposed long enough for someone to use it before maintenance lands.
Related resources from NHI Mgmt Group
- Is CVE-2022-0028 (Palo Alto Networks PAN-OS Reflected Amplification Denial-of-Service) being exploited in the wild?
- CVE-2022-0028 (Palo Alto Networks PAN-OS Reflected Amplification Denial-of-Service)
- How do you patch or mitigate CVE-2025-0111 (Palo Alto Networks PAN-OS File Read)?
- How do you patch or mitigate CVE-2024-9474 (Palo Alto Networks PAN-OS Management Interface OS Command Injection)?