Old Cisco SD-WAN Flaw Now Under Active Attack — Patch Immediately

Then, in February 2026, Cisco PSIRT updated its advisory with a stark warning: attempted exploitation of CVE-2022-20775 had been observed in the wild. The CVE record itself was updated on February 25, 2026, with Cisco's official statement: "In February 2026, the Cisco PSIRT became aware of attempted exploitation of the vulnerability described in CVE-2022-20775. Cisco continues to strongly recommend that customers upgrade to a fixed software release to remediate this vulnerability." Simultaneously, CISA's Vulnrichment team updated the CVE's SSVC (Stakeholder-Specific Vulnerability Categorization) metadata, marking the exploitation status as "active" and the technical impact as "total" — the highest possible rating — as of February 25, 2026 at 17:55 UTC.

The resurgence of this vulnerability nearly four years after its initial disclosure is a textbook example of threat actors mining legacy infrastructure for unpatched systems. SD-WAN deployments are notoriously slow to update: they are often classified as "critical infrastructure" by the IT teams managing them, change-control windows are narrow, and the fear of disrupting WAN connectivity keeps many organizations running older, known-vulnerable software versions for years. Attackers know this. The identity of the threat actors currently attempting exploitation remains unknown, and whether the observed attempts represent widespread automated scanning, targeted espionage-motivated attacks, or something else entirely has not yet been confirmed by Cisco or CISA.

Understanding the Vulnerability

At its core, CVE-2022-20775 is a local privilege escalation (LPE) vulnerability — meaning an attacker must already have some level of authenticated access to the device before they can exploit it. This is not a remote, unauthenticated exploit; it requires a foothold. However, that foothold can be as minimal as a standard, low-privileged user account, which in many enterprise environments is exactly the level of access a compromised vendor account, a lateral-moving attacker, or a malicious insider would possess. The CVSS v3.1 base score is 7.8 (HIGH), with the full vector string CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, reflecting that once local access is obtained, exploitation is low-complexity, requires only low privileges, needs no user interaction, and results in full compromise of confidentiality, integrity, and availability.

The root cause, classified under CWE-25 (Path Traversal: '/../filedir') and CWE-282 (Improper Ownership Management), lies in a chain of two interrelated bugs residing in two specific components of the Cisco SD-WAN software stack:

1. confd_cli_grp — a SUID (Set User ID) binary. A SUID binary is a program that, when executed, runs with the privileges of the file's owner (typically root) rather than the privileges of the user who invoked it. This is a legitimate and common Linux mechanism (think sudo, passwd), but it demands extremely careful input validation because any bug in a SUID binary can be a direct path to root.
2. libnss_viptela.so — a shared library used by the Cisco SD-WAN software for Name Service Switch (NSS) operations, specifically for user/group lookups (like getpwnam_r). This library contains the second path traversal flaw.

The Exploit Chain: Leaking the Secret Key to the Kingdom

The vulnerability exploitation is a sophisticated multi-step chain. Think of Cisco's SD-WAN CLI as a secured building managed by a central daemon called ConfD (Configuration Daemon). ConfD acts as a gatekeeper: before granting access to privileged configuration operations, it requires a digitally signed "voucher" from any process requesting to act on behalf of a user. The signing key for these vouchers is a secret stored in a file called /etc/viptela/confd_ipc_secret. If you can steal that secret, you can forge a voucher claiming to be root, hand it to the ConfD daemon, and walk through the front door with full administrative access.

Here is how the flaw allows that theft and forgery:

Step 1: The confd_cli_grp binary reads group configuration files using the USER environment variable. When confd_cli_grp is invoked, it constructs a file path to read the authenticated user's group configuration. It does this by concatenating a base directory with the value of the USER environment variable and the .external suffix, roughly as follows:

The critical failure here is that the value of USER is taken directly from the environment without sanitization. An attacker running in a restricted shell (vshell) can set USER to any arbitrary string, including one containing path traversal sequences like ../../../../tmp/pwn.

Step 2: libnss_viptela.so fails to catch the traversal during user validation. Before confd_cli_grp uses the constructed path, it calls getpwnam_r (a standard C library function to look up user information by name) to validate the value of USER. This call invokes libnss_viptela.so. The library's validation logic is supposed to ensure the provided username refers to a legitimate, existing system user. However, the library itself contains a path traversal flaw: if specific files exist in /tmp, the library incorrectly validates the malicious, traversal-containing username as legitimate. An attacker can pre-create the necessary files in /tmp (where any authenticated user typically has write access) to satisfy this broken check.

Step 3: The attacker creates a symlink in /tmp pointing to the secret. Before launching the exploit, the attacker creates a symbolic link (symlink) in /tmp:

A symlink is like a shortcut. When confd_cli_grp tries to read the file at its traversal-manipulated path (which resolves to /tmp/pwn.external), it actually reads the target of the symlink — /etc/viptela/confd_ipc_secret — the master IPC signing secret.

Step 4: The attacker intercepts the IPC communication using a local proxy. The confd_cli_grp binary, after reading the secret, uses it to conduct an Inter-Process Communication (IPC) handshake with the ConfD daemon. The attacker sets the CONFD_IPC_PORT environment variable to a port they control (e.g., port 1234) where they are running a local man-in-the-middle (MITM) proxy script. The binary connects to the attacker's proxy instead of the real daemon.

Step 5: The secret is captured, a forged credential is sent, and root is achieved. The proxy captures the confd_ipc_secret as it flies across the local IPC channel. The attacker's script then uses this captured secret to forge a new, validly-signed IPC message claiming the user's identity is uid=0, gid=0 — i.e., root. This forged message is forwarded to the real ConfD daemon. The daemon, seeing a validly-signed request, accepts it and grants the attacker a root shell.

The security research firm Orange CERT-CC (orangecertcc) documented the full technical details and published a proof-of-concept (PoC) exploit on October 10, 2022, in a GitHub Security Advisory (GHSA-wmjv-552v-pxjc). The PoC is a Python script. While we will not reproduce the exact weaponized exploit code in full, the advisory describes a script that performs the following automated steps:

The PoC was confirmed to work on vEdge hardware running both x86 and mips64 architectures. Given that all affected SD-WAN products (vBond, vManage, vSmart) share the same underlying Viptela software base and the same vulnerable components (confd_cli_grp and libnss_viptela.so), the exploit is expected to apply equally across all affected product lines, though explicit researcher validation on vBond, vManage, and vSmart specifically was inferred rather than individually documented.

The Full Attack Chain, Step by Step

1. Attacker acquires valid credentials for a low-privileged local user account on a Cisco SD-WAN device (through phishing, credential stuffing, purchasing from an initial access broker, or lateral movement from elsewhere in the network).
2. Attacker establishes a local shell by connecting to the device via SSH or a physical/virtual console, landing in the restricted vshell environment.
3. Attacker creates prerequisite files in /tmp: specifically, a symlink pwn.external pointing to /etc/viptela/confd_ipc_secret, and any other files required to satisfy libnss_viptela.so's broken validation check.
4. Attacker sets environment variables: USER is set to the path traversal string /../../../../tmp/pwn; CONFD_IPC_PORT is set to a local port (e.g., 1234) controlled by the attacker's MITM proxy script.
5. Attacker launches the MITM proxy script on the local port, ready to intercept IPC traffic.
6. Attacker executes the SUID binary confd_cli_grp. Due to the USER traversal and libnss_viptela.so validation failure, the binary reads /etc/viptela/confd_ipc_secret via the symlink and transmits it to the attacker's local proxy.
7. Attacker's proxy captures the secret, forges a new IPC session configuration claiming uid=0 (root) and gid=0 (root group), signs it with the stolen secret, and forwards it to the real ConfD daemon.
8. The ConfD daemon accepts the validly-signed forged credential and grants the attacker a fully unconstrained root shell.
9. The attacker has complete control of the underlying operating system of the SD-WAN device.

Who Is Affected

The vulnerability affects the core components of Cisco's SD-WAN (formerly Viptela) platform. Cisco IOS XE SD-WAN Software is explicitly NOT affected. The affected product families are:

Patch Availability by Software Train

This is not just a patch for a handful of customers. The breadth of affected versions — stretching from version 17.2.4 all the way through 20.6.8, encompassing dozens of minor and maintenance releases spanning nearly a decade of SD-WAN software history — reflects just how deeply embedded vulnerable code was across the product line. SD-WAN is not a niche technology: it is widely deployed by enterprises, managed service providers, government agencies, and critical infrastructure operators worldwide to manage and secure WAN connectivity across hundreds or thousands of sites simultaneously.

Real-World Risk

Cisco SD-WAN is not a peripheral system. It is the nervous system of an enterprise's wide-area network. The vManage controller is the centralized management plane — the single pane of glass through which administrators configure every router, policy, and security rule. The vSmart controller is the intelligence layer, computing and distributing routing policies. The vBond orchestrator handles device authentication and onboarding. The vEdge routers are the data plane — the physical and virtual devices actually forwarding enterprise traffic at every branch, data center, and cloud on-ramp. Owning root on any of these components is extraordinarily dangerous.

With root access to a vManage instance, an attacker can:

• Read every network configuration, topology map, device certificate, and credential stored in the management plane.
• Modify routing policies to redirect traffic through attacker-controlled nodes, enabling enterprise-wide man-in-the-middle attacks.
• Push malicious configurations to all managed vEdge routers simultaneously.
• Install persistent backdoors or rootkits that survive reboots and even some software update processes.
• Exfiltrate VPN keys, IPSec credentials, and other cryptographic material used to secure inter-site WAN tunnels.
• Use vManage as a pivot point for lateral movement into the broader enterprise network.

With root access to a vEdge router or vSmart controller, an attacker can:

• Intercept and inspect (or modify) all traffic flowing through that router — including traffic from internal users to cloud services, between branch offices, and to data centers.
• Extract routing tables revealing the complete internal network architecture.
• Disrupt WAN connectivity for all sites served by the compromised router or controller, effectively causing a denial of service for potentially hundreds of remote locations.
• Deploy persistent monitoring tools to conduct long-term, covert espionage against the organization's network communications.

The data at risk from a successful exploitation includes: device configurations, routing tables, VPN credentials, network topology information (a roadmap to the entire enterprise), the confd_ipc_secret itself (which could enable further forgery attacks), and potentially all network traffic flowing through the compromised device.

The fact that a public, working proof-of-concept exploit has been available since October 10, 2022 — published by Orange CERT-CC — means that the barrier to exploitation for any attacker who can acquire a valid low-privileged credential is extremely low. The exploit chain, while technically sophisticated in its design, is fully automated by the PoC script. An attacker does not need to deeply understand the internals of ConfD or Linux NSS to weaponize it.

According to CISA's SSVC assessment (updated February 25, 2026), this vulnerability is rated as "no" for automatable — meaning mass, fully automated internet-scale exploitation without any prior access is not feasible due to the local authentication requirement. However, the technical impact is rated "total", meaning successful exploitation results in complete system compromise. The combination of a low exploitation bar for authenticated attackers, a public PoC, confirmed in-the-wild exploitation, and the critical nature of the targeted systems makes this an extremely high-priority remediation item.

The identity of the threat actors targeting CVE-2022-20775 in February 2026 has not been confirmed by Cisco, CISA, or any public threat intelligence source at the time of writing. It is not known whether the observed exploitation attempts are part of a ransomware campaign, a nation-state espionage operation, or opportunistic scanning by financially motivated criminals. What is known is that the attempts were serious enough for Cisco PSIRT to update the official CVE record and for CISA to reference an Emergency Directive (ED 26-03) in connection with the KEV catalog listing.

What You Should Do

Cisco has been unequivocal: there are no workarounds or configuration changes that mitigate this vulnerability. The only remediation is upgrading to a fixed software version. Given that active exploitation is underway, this must be treated as an emergency patching event, not a routine maintenance item.

Immediate Actions (Do These Now)

1. Take inventory. Immediately identify all Cisco SD-WAN components in your environment: every vManage instance, every vSmart controller, every vBond orchestrator, and every vEdge router (both physical hardware and cloud/virtual instances). Include the SD-WAN vContainer. Do not assume your inventory is current — SD-WAN deployments often grow organically.
2. Check your software versions. For every identified device, determine the exact software version. If you are running any version in the 17.x, 18.x, 19.x, 20.1, 20.3, 20.4, or 20.5 software trains, you have no backported fix available and must migrate to a fixed release. If you are running 20.6.x (prior to 20.6.3), 20.7.x (prior to 20.7.2), or 20.8.x (prior to 20.8.1), backported fixes are available.
3. Prioritize CVE-2022-20775 remediation. This is the actively exploited flaw. Get to 20.6.3, 20.7.2, or 20.8.1 at minimum on your respective software trains if an immediate upgrade to 20.9 is not operationally feasible. Acknowledge that doing so leaves CVE-2022-20818 unpatched, and plan an accelerated timeline to reach 20.9.
4. Upgrade to 20.9 or later for complete coverage. Version 20.9 is confirmed "not affected" by both CVE-2022-20775 and CVE-2022-20818. This is the recommended end-state. Consult Cisco's software compatibility matrices and release notes to plan your upgrade path carefully, as major version upgrades in SD-WAN environments require staged planning (vManage first, then vSmart/vBond, then vEdge).
5. Audit local user accounts. Review all local user accounts configured on your SD-WAN appliances. Remove any accounts that are no longer needed. An attacker cannot exploit this vulnerability without a valid credential, so reducing the number of valid credentials reduces your exposure window while patches are being applied.
6. Restrict CLI/shell access. While not a full mitigation, ensuring that SSH and console access to SD-WAN devices is restricted to known, trusted administrator IP addresses via access-control lists (ACLs) or out-of-band management networks reduces the attack surface during the patching window.

Patch Reference Table

Patches and upgrade instructions are available through Cisco's Security Advisory page: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sd-wan-priv-E6e8tEdF (https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sd-wan-priv-E6e8tEdF). A valid Cisco support contract may be required to download software.

Detection: How to Hunt for Signs of Compromise

If you suspect your environment may have already been targeted — particularly given the February 2026 start date for observed exploitation attempts — the following indicators of compromise (IOCs) and log review guidance may help identify intrusion activity:

File System Indicators:

• Look for unexpected files in /tmp with the .external suffix. Specifically, look for symlinks in /tmp with names like pwn.external or any .external file that points to /etc/viptela/confd_ipc_secret or other sensitive configuration files.
• Check /tmp for any unexpected files that may have been created to satisfy the libnss_viptela.so validation bypass.

Process and Environment Indicators:

• Search process execution logs or shell history for invocations of confd_cli_grp where the environment contains a USER variable with path traversal sequences (../ or /../../../../).
• Look for processes listening on non-standard local ports that may indicate a MITM proxy was established to intercept IPC traffic.

Log-Based Indicators:

• Review CLI audit logs for command execution by low-privileged users that would normally require root access.
• Look for shell history entries containing export USER= with unusual values.
• Check syslog for entries related to the confd daemon receiving unexpected or invalid connection attempts — a failed or partially successful exploitation attempt may leave error traces.
• Review authentication logs for any elevation to root from non-root user accounts, particularly from accounts that have no legitimate administrative function.

Detection Rules:

• Monitor file system events for symlink creation in /tmp targeting files under /etc/viptela/.
• Create process monitoring rules to alert on execution of confd_cli_grp when the parent process environment contains the string ../ in the USER variable.
• Monitor for IPC traffic on ports other than the default ConfD IPC port.

CISA's KEV catalog entry for CVE-2022-20775 also references "Hunt & Hardening Guidance for Cisco SD-WAN Devices" — defenders should consult CISA's guidance directly for additional threat hunting playbooks tailored to this advisory.

The Bigger Picture

The reemergence of CVE-2022-20775 as an actively exploited threat in early 2026 — nearly four years after it was publicly disclosed and patched — is not an anomaly. It is a pattern. Security researchers and threat intelligence teams have documented a consistent trend of sophisticated threat actors, particularly those focused on network infrastructure, returning to years-old vulnerabilities that were never patched in legacy or hard-to-update deployments. We saw this with Ivanti VPN appliances, Fortinet SSL-VPN devices, and Citrix ADC systems, where vulnerabilities disclosed in one year became the centerpiece of major espionage campaigns in subsequent years.

Network infrastructure — SD-WAN controllers, routers, VPN gateways, firewalls — represents an extraordinarily high-value target precisely because it is so difficult to patch. These devices sit at the intersection of all enterprise traffic. They are rarely monitored with the same endpoint detection and response (EDR) tools deployed on Windows workstations. They often run proprietary, embedded operating systems that make forensic analysis after compromise extremely difficult. And they are almost never rebooted outside of maintenance windows, meaning a persistent implant installed on a compromised router may go undetected for months or years.

The companion vulnerability CVE-2022-20818, disclosed in the same September 2022 advisory, has not yet been reported as exploited in the wild as of February 26, 2026. However, given the pattern of exploitation we are seeing with CVE-2022-20775, organizations should treat CVE-2022-20818 as a pending threat and not defer full remediation (i.e., upgrading to version 20.9) indefinitely simply because it has not yet been weaponized. The PoC for CVE-2022-20775 is public. The technical community understands the underlying vulnerability class (path traversal in Viptela's IPC mechanism). CVE-2022-20818 shares the same CWE classifications and the same advisory. It would be prudent to assume that its exploitation is a matter of when, not if.

For organizations that have not yet adopted Cisco's newer Catalyst SD-WAN platform on the IOS XE software train (which is confirmed not affected by this vulnerability class), this incident may also be an impetus to evaluate platform migration timelines. The legacy Viptela-based software stack has a substantial vulnerability history in its CLI and IPC mechanisms, and the oldest affected versions (17.x, 18.x) are well beyond any reasonable support lifecycle.

Finally, this incident underscores a fundamental principle of enterprise security hygiene: the principle of least privilege must apply even to network operators. Any user with a valid low-privileged account on a Cisco SD-WAN device can exploit this vulnerability to become root. The attack surface is every person, every service account, and every compromised credential that has any level of local access to your SD-WAN appliances. Reducing that surface — through strict access control, multi-factor authentication, privileged access workstations, and aggressive account lifecycle management — is not a substitute for patching, but it is the critical defense-in-depth measure that makes the difference between an attacker who can exploit a flaw and one who cannot get to the starting line.

Patch first. Hunt for compromise second. Harden access controls third. And do not let a 2022 vulnerability become your 2026 breach.