← Back to Feed CACHED · 2026-09-26 08:59:32 · CACHE_KEY CVE-2026-20224
CVE-2026-20224 · CWE-20 · Disclosed 2026-05-14

Cisco Catalyst SD-WAN Manager Unauthenticated XML External Entity Injection

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone left the filing cabinet unlocked in your network's control tower

CVE-2026-20224 is an XML External Entity (XXE) injection vulnerability in the web UI of Cisco Catalyst SD-WAN Manager (formerly vManage). The XML parser in the web interface fails to disable external entity resolution, allowing an unauthenticated, remote attacker to send a crafted XML request that forces the application to read arbitrary files from the underlying Linux host — /etc/passwd, configuration YAML, database credentials, TLS private keys, you name it. The flaw uses a blind XXE technique: file contents are exfiltrated out-of-band to an attacker-controlled server rather than reflected in the HTTP response. Affected versions span an enormous range from 17.2.4 through 26.1, with fixes landing in 20.9.9.1, 20.12.5.4, 20.12.6.2, 20.12.7.1, 20.15.4.4, 20.15.5.2, 20.18.2.2, and 26.1.1.1. Bug ID: CSCwt55544.

Cisco's HIGH / 8.6 rating is broadly fair but slightly generous. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N) correctly captures the unauthenticated-remote, no-interaction nature and the high confidentiality impact crossing security boundaries. However, the blind XXE mechanic requires the attacker to stand up an out-of-band exfiltration server and the target vManage to have outbound connectivity to it — a practical friction point the CVSS base score doesn't model. Additionally, the impact is read-only: no code execution, no file write, no denial of service from the XXE itself. That said, the *content* readable on a vManage host — admin hashes, API tokens, NETCONF keys — converts this from 'information disclosure' to 'credential harvesting for full fabric takeover,' which the 8.6 doesn't quite capture in its implications either. noisgate adjusts to 8.2 on balance: the blind-XXE friction shaves a fraction off, but the management-plane target role keeps it firmly HIGH.

"Unauthenticated XXE on SD-WAN Manager leaks credentials that own the fabric"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Locate SD-WAN Manager web UI

The attacker identifies an internet-facing or internally reachable Cisco Catalyst SD-WAN Manager instance. Shodan, Censys, and FOFA collectively index 450–1,000 internet-exposed instances; internal instances are reachable post-initial-access. The default web UI listens on TCP/8443 with a distinctive Cisco login page and TLS certificate CN.
Conditions required:
  • Network reachability to the vManage web UI (TCP/8443 or TCP/443)
Where this breaks in practice:
  • Most enterprise deployments restrict vManage to an out-of-band management VLAN, not the general corporate LAN or internet
  • ~450–1,000 internet-exposed instances is a small global footprint compared to, e.g., Exchange or FortiGate
Detection/coverage: Shodan/Censys dork: http.title:"vManage" or ssl.cert.subject.CN:"vmanage". Tenable plugin 315344 detects the vulnerable version remotely.
STEP 02

Craft blind XXE payload with OOB exfiltration

The attacker builds an XML document containing an external entity declaration that references a DTD file hosted on their server. The DTD instructs the parser to read a local file (e.g., /etc/shadow, /opt/vmanage/db/config.json) and send its contents as a URL parameter to the attacker's listener. A public PoC by fevar54 on GitHub (Cisco Catalyst.py + malicious DTD) automates this entire flow.
Conditions required:
  • Attacker-controlled server reachable from the vManage host (for OOB data exfiltration)
  • Knowledge of target file paths on the vManage Linux OS
Where this breaks in practice:
  • Outbound connectivity from vManage to arbitrary internet hosts may be blocked by firewall policy
  • Blind XXE is noisier than direct-response XXE — requires two network interactions instead of one
Detection/coverage: Outbound HTTP/DNS from the vManage host to unusual IPs/domains is detectable via DNS logging, proxy logs, or NDR. Look for vManage initiating connections it never normally would.
STEP 03

Exfiltrate sensitive files

The XML parser resolves the external entity, reads the target file, and transmits its contents to the attacker's OOB listener. High-value targets on vManage include /etc/shadow (local OS hashes), Neo4j database credentials, admin API tokens, NETCONF/SSH private keys, and SD-WAN fabric overlay certificates. Each file read is a separate request, so the attacker iterates.
Conditions required:
  • Successful OOB channel established in step 2
  • Target files exist and are readable by the vManage web service process (typically root or vmanage user)
Where this breaks in practice:
  • Some file contents (binary, very large) may fail to exfiltrate cleanly via URL-parameter-based blind XXE
  • Rate-based anomaly detection may flag repeated unusual XML requests to the web UI
Detection/coverage: IDS/IPS signatures for XXE payloads in HTTP request bodies (e.g., Snort SID for <!ENTITY in POST data). WAF rules blocking XML with DTD declarations.
STEP 04

Leverage stolen credentials for fabric takeover

With admin credentials or API tokens harvested from the vManage file system, the attacker authenticates to the vManage REST API or SSH/NETCONF interface. From the management plane, they can push arbitrary configuration changes to every SD-WAN edge router in the fabric — rerouting traffic, disabling security policies, or establishing persistent backdoor tunnels. This step converts a read-only vuln into full infrastructure compromise.
Conditions required:
  • Credential material found in exfiltrated files is current and valid
  • vManage API/SSH access is reachable from the attacker's position
Where this breaks in practice:
  • If vManage uses external IdP (RADIUS/TACACS+/SAML) for admin auth, local credential files may not contain usable passwords
  • MFA on admin logins would block credential reuse even with valid hashes
Detection/coverage: Anomalous admin logins from unexpected source IPs. Configuration change audit logs on vManage showing unauthorized policy pushes.
03 · Compensating Control

1
HIGH 8.2→MEDIUM 5.5
SEVERITY REDUCED
Restrict vManage web UI access to jump-host / management VLAN only — Apply firewall ACLs or security-group policy to ensure TCP/8443 (and TCP/443 if aliased) on vManage is reachable only from designated management jump hosts or a PAM gateway. This breaks the attack path at step 1 by eliminating unauthenticated remote access from untrusted networks. Deploy within 30 days per the noisgate mitigation SLA for HIGH findings.
2
HIGH 8.2→MEDIUM 5.0
SEVERITY REDUCED
Block outbound internet from vManage hosts — Configure egress firewall rules to deny vManage hosts from initiating connections to the internet (or any network outside the management VLAN). This breaks the blind XXE OOB exfiltration channel at step 2 — the parser can read files but has no way to send them to the attacker. Particularly effective because this CVE uses *blind* XXE exclusively. Deploy within 30 days.
3
HIGH 8.2→MEDIUM 6.0
SEVERITY REDUCED
Enable MFA for all vManage admin accounts — Even if an attacker exfiltrates credential material from the file system, MFA on admin logins prevents credential reuse at step 4. Use SAML/RADIUS with an external IdP that enforces MFA. This doesn't prevent the file read but blocks the fabric-takeover escalation. Deploy within 30 days.
4
HIGH 8.2→LOW 3.5
SEVERITY REDUCED
Deploy WAF or IPS rule blocking XXE in XML requests — Place a WAF (or enable IPS signatures) in front of the vManage web UI that strips or blocks XML requests containing <!DOCTYPE or <!ENTITY declarations. Cisco provides no built-in workaround, so this is the nearest in-line mitigation. Snort/Suricata community rules exist for generic XXE detection. Deploy within 30 days.
5
HIGH 8.2→IGNORE 0.0
SEVERITY REDUCED
Patch to a fixed release — Upgrade Cisco Catalyst SD-WAN Manager to 20.9.9.1, 20.12.5.4, 20.12.6.2, 20.12.7.1, 20.15.4.4, 20.15.5.2, 20.18.2.2, or 26.1.1.1 depending on your release train. This is the definitive fix. Target the 180-day noisgate remediation SLA for HIGH, but accelerate if UAT-8616 activity expands to this CVE.
What doesn't work
  • Disabling the vManage web UI entirely — not practical; the web UI is the primary management interface for the SD-WAN fabric and disabling it would cripple day-to-day operations.
  • Network segmentation of SD-WAN edge devices — doesn't help because the vulnerability is on the *manager*, not the edges. Segmenting edges from each other doesn't prevent file read on vManage.
  • Rotating local admin passwords alone — the XXE can read *any* file, not just password stores. API tokens, certificates, and database credentials would still be exposed. Password rotation is necessary but not sufficient.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNot confirmed. CVE-2026-20224 is not in CISA KEV and no vendor or threat-intel report documents active exploitation. However, threat group UAT-8616 has been actively chaining other SD-WAN Manager CVEs (CVE-2026-20127, CVE-2026-20182, CVE-2026-20122, CVE-2026-20128) throughout 2026, making this a high-probability future target.
Proof-of-conceptPublic. GitHub repo fevar54/CVE-2026-20224 provides a Python exploit script (Cisco Catalyst.py) and a DTD file for blind XXE exfiltration. Functional and straightforward to use.
EPSS0.01036 (1.04%), approximately 61st percentile. Relatively low exploitation probability model score, reflecting no observed exploitation yet.
KEV statusNot listed. Not added to CISA Known Exploited Vulnerabilities catalog as of 2026-09-26.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N — Network-accessible, low complexity, no auth, no user interaction, scope changed (reads host files beyond the web app sandbox), high confidentiality impact, no integrity or availability impact.
Affected versionsCisco Catalyst SD-WAN Manager 17.2.4 through 26.1 — an enormous range covering nearly every release train in the product's history.
Fixed versions20.9.9.1, 20.12.5.4, 20.12.6.2, 20.12.7.1, 20.15.4.4, 20.15.5.2, 20.18.2.2, 26.1.1.1
Internet exposure~450–1,000 instances visible across Shodan (~500), Censys (~550–600), and FOFA (~1,000+) per VulnCheck research. Small absolute number but each instance controls an entire SD-WAN fabric.
Disclosure date2026-05-14 (reserved 2025-10-08). Advisory: cisco-sa-sdwan-mltvnps2-JxpWm7R
ReporterNot publicly attributed. Cisco internal finding (Bug ID: CSCwt55544).

Sources.

  1. Cisco Security Advisory cisco-sa-sdwan-mltvnps2-JxpWm7R
  2. NVD — CVE-2026-20224
  3. OpenCVE — CVE-2026-20224
  4. PoC: fevar54/CVE-2026-20224 XXE Injection (GitHub)
  5. VulnCheck — Cisco SD-WAN Manager Vulnerabilities
  6. CyberStrike — CVE-2026-20224 Detail
  7. CSA Singapore — Vulnerability in Cisco Catalyst SD-WAN Manager
  8. Help Net Security — Cisco SD-WAN zero-day coverage
05 · The Call

Final Verdict
= UNCHANGED to HIGH (8.2/10)

Why this verdict

  • Blind XXE friction: The exploit requires an out-of-band exfiltration channel — the attacker must host a DTD server *and* the vManage host must have outbound connectivity to it. This is a meaningful friction point that the CVSS base score's AC:L doesn't capture. Modest downward pressure: −0.2.
  • Read-only impact: The vulnerability provides arbitrary file read, not code execution or file write. The CVSS correctly scores I:N/A:N, but the practical gap between 'read a file' and 'own the box' requires an additional credential-harvesting step that may not always succeed (e.g., external IdP, MFA). Downward pressure: −0.2.
  • Management-plane exposure model: Most enterprises deploy vManage on an isolated management network. Shodan/Censys show only ~500–1,000 internet-exposed instances globally. For the majority of the installed base, exploitation requires prior internal network access — meaning the attacker is already post-initial-access. Framing as a post-compromise amplifier rather than an initial-access vector for most deployments.
  • Role multiplier: Cisco Catalyst SD-WAN Manager is canonically a high-value-role component — 100% of its installs *are* the centralized management and orchestration plane for the SD-WAN fabric. A successful file-read chain exposes admin credentials, API tokens, NETCONF keys, and overlay certificates. With those, the attacker achieves fleet-scale blast radius: full control over every SD-WAN edge router in the fabric (traffic rerouting, policy disablement, persistent backdoor tunnels). This is network-infrastructure-scale compromise, analogous to owning vCenter or a domain controller. The verdict floor is HIGH based on the high-value-role rule; the chain demonstrably succeeds in this canonical role.
  • Threat-actor adjacency: UAT-8616 has been actively chaining SD-WAN Manager CVEs throughout 2026 (CVE-2026-20127, CVE-2026-20182, CVE-2026-20122, CVE-2026-20128). CVE-2026-20224 sits in exactly the same attack surface and could be folded into their toolchain at any time. This is upward pressure that prevents further downgrade.

Why not higher?

CRITICAL would require either direct code execution, confirmed active exploitation, or a fully pre-auth chain with no friction gates. CVE-2026-20224 is read-only, uses blind XXE requiring an OOB channel, and has no confirmed in-the-wild exploitation. The credential-harvesting-to-fabric-takeover chain is plausible but requires an additional pivot step, and MFA or external IdP usage would break it. The ~500 internet-exposed instances represent a small fraction of the global installed base, limiting the initial-access population.

Why not lower?

MEDIUM would ignore the deployment-role reality: this component IS the SD-WAN management plane, and the files readable via XXE include the exact credential material needed for full fabric takeover. A public PoC exists, the attack is unauthenticated with no user interaction, and an active threat group (UAT-8616) is already operating in this exact attack surface. The floor is HIGH by the high-value-role rule — SD-WAN Manager is canonically a network orchestration platform where ≥10% (in fact 100%) of installs occupy the high-value role.

06 · Verification

Crowdsourced verification payload.

Run this script on each Cisco Catalyst SD-WAN Manager host via SSH (or console). It requires shell access as admin or root. Invoke with: bash check_cve_2026_20224.sh. The script parses the running vManage software version and compares it against known fixed releases.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_20224.sh
# Checks whether Cisco Catalyst SD-WAN Manager is vulnerable to CVE-2026-20224
# (XXE Injection - arbitrary file read)
# Run on the vManage host via SSH as admin or root.
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

get_version() {
  # Try vManage CLI first
  if command -v vmanage &>/dev/null; then
    vmanage show version 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9.]+' | head -1 && return
  fi
  # Fallback: parse /etc/os-release or build info
  if [ -f /etc/viptela-version ]; then
    cat /etc/viptela-version | grep -oP '[0-9]+\.[0-9]+\.[0-9.]+' | head -1 && return
  fi
  # Fallback: show system status via viptela CLI
  if command -v show &>/dev/null; then
    show system status 2>/dev/null | grep -i 'version' | grep -oP '[0-9]+\.[0-9]+\.[0-9.]+' | head -1 && return
  fi
  echo ""
}

version_gte() {
  # Returns 0 if $1 >= $2 using sort -V
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -1)" = "$2" ]
}

VERSION=$(get_version)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - Could not determine vManage version."
  echo "Manually verify with: show system status | grep version"
  exit 2
fi

echo "Detected vManage version: $VERSION"

# Fixed versions per release train:
# 20.9.x  -> 20.9.9.1
# 20.12.x -> 20.12.5.4 (earliest fix in train)
# 20.15.x -> 20.15.4.4
# 20.18.x -> 20.18.2.2
# 26.x    -> 26.1.1.1

MAJOR_MINOR=$(echo "$VERSION" | grep -oP '^[0-9]+\.[0-9]+')

case "$MAJOR_MINOR" in
  20.9)
    if version_gte "$VERSION" "20.9.9.1"; then
      echo "PATCHED - Version $VERSION >= 20.9.9.1"
      exit 0
    fi
    ;;
  20.10|20.11)
    echo "VULNERABLE - Release train $MAJOR_MINOR has no fix; migrate to a supported train."
    exit 1
    ;;
  20.12)
    if version_gte "$VERSION" "20.12.5.4"; then
      echo "PATCHED - Version $VERSION >= 20.12.5.4"
      exit 0
    fi
    ;;
  20.13|20.14)
    echo "VULNERABLE - Release train $MAJOR_MINOR has no fix; migrate to a supported train."
    exit 1
    ;;
  20.15)
    if version_gte "$VERSION" "20.15.4.4"; then
      echo "PATCHED - Version $VERSION >= 20.15.4.4"
      exit 0
    fi
    ;;
  20.16|20.17)
    echo "VULNERABLE - Release train $MAJOR_MINOR has no fix; migrate to a supported train."
    exit 1
    ;;
  20.18)
    if version_gte "$VERSION" "20.18.2.2"; then
      echo "PATCHED - Version $VERSION >= 20.18.2.2"
      exit 0
    fi
    ;;
  26.1)
    if version_gte "$VERSION" "26.1.1.1"; then
      echo "PATCHED - Version $VERSION >= 26.1.1.1"
      exit 0
    fi
    ;;
  26.*)
    if version_gte "$VERSION" "26.1.1.1"; then
      echo "PATCHED - Version $VERSION >= 26.1.1.1"
      exit 0
    fi
    ;;
  *)
    if version_gte "$VERSION" "26.1.1.1"; then
      echo "PATCHED - Version $VERSION is at or above the latest fix."
      exit 0
    fi
    echo "VULNERABLE - Version $VERSION (train $MAJOR_MINOR) is in the affected range."
    exit 1
    ;;
esac

echo "VULNERABLE - Version $VERSION is below the fixed release for the $MAJOR_MINOR train."
exit 1