How do you patch or mitigate CVE-2022-20775 (Cisco SD-WAN Path Traversal)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

CISA's required action for CVE-2022-20775 is to please adhere to CISA’s guidelines to assess exposure and mitigate risks associated with Cisco SD-WAN devices as outlines in CISA’s Emergency Directive 26-03 (URL listed below in Notes) and CISA’s “Hunt & Hardening Guidance for Cisco SD-WAN Devices (URL listed below in Notes). Adhere to the applicable BOD 22-01 guidance for cloud services or discontinue use of the product if mitigations are not available.

What makes CVE-2022-20775 a patch-or-mitigate problem, not just a version check?

CVE-2022-20775 is a Cisco SD-WAN path traversal issue that CISA placed in the KEV catalogue on 2022-03-30 and directed organisations to assess exposure and mitigate risk using Emergency Directive 26-03. Because the issue is in actively targeted network infrastructure, the practical question is not only whether a device is vulnerable, but whether it can be reached, constrained, and verified as clean after remediation.

When a flaw is in the KEV catalogue, treat the device as part of an active exploitation problem set, not a routine maintenance item. CISA Known Exploited Vulnerabilities Catalog is the right place to confirm the urgency, while the vendor advisory remains the source for exact affected and fixed release details.

A path traversal weakness matters because it can let an attacker reach files or paths that were not intended to be exposed, which can in turn undermine configuration integrity, credential material, or device trust assumptions. For SD-WAN appliances, the security concern is not only data exposure, but the possibility that the device becomes a foothold in a routed or centrally managed environment.

How should you confirm exposure and handle the fix path?

Start by inventorying every Cisco SD-WAN device and identifying which instances are internet-facing, remotely administered, or reachable from less trusted segments. Then compare each instance against the Cisco advisory and CISA guidance, because mitigation decisions depend on the exact product condition and deployment pattern, not on the CVE name alone. The vendor advisory and the KEV entry should be your authoritative references for the patch path.

If patching is available, prioritise the exposed management plane first and validate that the device is no longer advertising the vulnerable service path once remediation is complete. CVE Program records help anchor the identifier, while the advisory should drive the exact release selection and deployment order.

If patching must wait, use the smallest defensible mitigation set that reduces external reachability and limits who can interact with the device. That usually means tightening management access, restricting source addresses, and applying the CISA hardening guidance rather than relying on compensating controls that do not materially block traversal attempts. NIST Cybersecurity Framework 2.0 is a useful broad control lens, but the remediation decision itself should still be driven by vendor and CISA instructions.

What should you check before you close the incident?

After mitigation or patching, look for signs that the device was already used as an access point. That includes unexpected configuration changes, unusual authentication events, new administrative accounts, altered routing or policy settings, and any file or process artefacts that indicate post-exploitation activity. For an edge or control-plane device, the question is not only whether the CVE is fixed, but whether the compromise window was already used.

Where the device handled secrets, sessions, certificates, or trust relationships, rotate the material that could have been exposed and invalidate anything that may have been cached or reused elsewhere. If you cannot establish a trustworthy before-and-after state, treat the device as potentially impacted and widen the review to adjacent systems that depend on it for control or connectivity. NIST Cybersecurity Framework 2.0 supports this broader recover-and-verify mindset, but the evidence check itself should be specific to the SD-WAN environment.

Risk and Threat Considerations

CVE-2022-20775 sits in a high-value class of edge-device flaws because exposure can extend beyond a single appliance into network reachability, policy control, and downstream administrative trust. If the device is externally accessible or centrally managed, a weak mitigation posture can turn a traversal flaw into a broader compromise opportunity.

Failure mechanism: An attacker abuses path traversal to reach unintended filesystem locations or internal resources, then uses whatever the device exposes to deepen access, alter configuration, or stage follow-on activity.

Impact: The likely consequence is not just local file exposure, but control-plane compromise, persistence risk, and potential spillover into the wider SD-WAN or adjacent management environment.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-1 — Inventory and Control of Enterprise Assets	Asset inventory is needed to find exposed Cisco SD-WAN devices.
Recommendation — Maintain an accurate asset inventory and flag all SD-WAN devices for urgent review.
NIST CSF 2.0	ID.AM-01 — Physical devices and systems within the organization are inventoried	This vulnerability response starts with locating every affected SD-WAN system.
Recommendation — Inventory all Cisco SD-WAN devices and identify which are externally reachable.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The page is about assessing exposure and remediating a known exploited vulnerability.
	SI-2 — Flaw Remediation	This CVE requires timely patching or mitigation on affected devices.
	CM-7 — Least Functionality	Restricting exposed management functionality helps reduce exploitability while patching waits.
Recommendation — Scan for the vulnerable condition and track remediation to closure. Apply the vendor fix or approved mitigation as soon as exposure is confirmed. Disable or restrict unnecessary management access paths until remediation is complete.

Practitioner Guidance

What to prioritise: Treat externally reachable SD-WAN management exposure as the first remediation tier. If the device cannot be patched immediately, reduce exposure before you spend time on lower-value validation tasks.

What to verify: Confirm that the mitigation actually blocks the vulnerable path and that the device is still operating within expected management boundaries. Verification should include post-change testing, not just a successful configuration push.

Escalation / exception: If the environment depends on a device that cannot be remediated or meaningfully constrained, escalate it as a residual-risk exception and decide quickly whether continued use is acceptable under the organisation’s risk tolerance.

Practitioner takeaway: For KEV-class edge flaws, the right sequence is exposure assessment, mitigation or patching, and compromise verification, because fixing the CVE without validating the device’s trust state leaves the hardest part unresolved.

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 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org