← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-20122 · CWE-648 · Disclosed 2026-02-25

Cisco Catalyst SD-WAN Manager Arbitrary File Overwrite Vulnerability

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a spare key hidden inside the breaker room, not a front-door smash

CVE-2026-20122 is an arbitrary file overwrite bug in the Cisco Catalyst SD-WAN Manager API. In the vulnerable trains, an attacker with valid read-only API credentials can upload data that lands where it should not on the local filesystem, which can be turned into vmanage user access. Affected releases are broad: earlier than 20.9 must migrate, 20.9 before 20.9.8.2, 20.10/20.11 before 20.12.6.1, 20.12 before 20.12.5.3 plus 20.12.6, 20.13–20.15 before 20.15.4.2, and 20.16–20.18 before 20.18.2.1.

The original CNA/MITRE record labeled this MEDIUM 5.4, but that underrates reality for defenders because this bug is now KEV-listed and Cisco/Talos have tied it to real exploitation chains against exposed SD-WAN Manager systems. That said, the vendor-freefall into 'critical' still overstates the standalone case: by itself this is not unauthenticated initial access, and in most sane enterprises it needs either prior credentials or chaining with CVE-2026-20133 and CVE-2026-20128.

"KEV and real-world chaining push this above medium, but the credential prerequisite keeps it out of critical"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a reachable SD-WAN Manager

The attacker needs a Cisco Catalyst SD-WAN Manager node reachable over its management/API surface. In the widespread cases Talos described, the starting point was internet-exposed or otherwise broadly reachable management infrastructure, with public PoC activity after March 2026. Tooling observed in the wild included the ZeroZenX Labs PoC referenced by Cisco Talos.
Conditions required:
  • SD-WAN Manager is reachable from the attacker network path
  • Target is running a vulnerable 20.x release
  • Management/API exposure is not tightly restricted
Where this breaks in practice:
  • Many enterprises keep SD-WAN management behind VPNs or admin enclaves
  • Exposure population is meaningful but not internet-massive; VulnCheck saw hundreds, not millions, of exposed instances
  • Asset discovery for this product is easy for internet-facing nodes, much harder for internal-only deployments
Detection/coverage: External attack surface tools can usually spot exposed nodes; scanner coverage for the precise chain is uneven, but exposure discovery is straightforward.
STEP 02

Satisfy the credential prerequisite or bypass it via chaining

Standalone exploitation of CVE-2026-20122 requires read-only API credentials. In the real intrusions Talos documented, attackers instead chained CVE-2026-20133 and CVE-2026-20128 to recover sensitive data and DCA access, then used that foothold to make CVE-2026-20122 practical without legitimate admin onboarding.
Conditions required:
  • Either valid read-only API access exists
  • Or companion flaws CVE-2026-20133 and CVE-2026-20128 are also present and reachable
Where this breaks in practice:
  • This is the biggest brake on severity: CVE-2026-20122 alone is not unauthenticated initial access
  • Credential hygiene, MFA on admin workflows, and network segmentation reduce the odds of reaching this step directly
  • If companion flaws are patched or the host is on 20.18.2.1+ for the later trains, the observed chain breaks
Detection/coverage: Look for suspicious reads to DCA-related paths and unusual API use from non-admin IPs; Cisco published IoCs for the chain in serviceproxy-access.log.
STEP 03

Overwrite a file through the API

With the prerequisite satisfied, the attacker abuses the vulnerable API file handling to place or overwrite files on disk. In practice this has been used to stage server-side payloads, including JSP webshells such as Talos' named XenShell, as well as Behinder and Godzilla variants.
Conditions required:
  • API access accepted by the target
  • Writable path reached through the vulnerable upload/overwrite logic
Where this breaks in practice:
  • Exploit success depends on landing the file in a path that produces execution or privilege transition
  • Application and filesystem hardening can reduce useful landing zones
  • Clustered deployments may require node-by-node follow-through
Detection/coverage: Cisco IoC example for CVE-2026-20122 is a POST /dataservice/smartLicensing/uploadAck entry in /var/log/nms/containers/service-proxy/serviceproxy-access.log; Talos also published Snort SIDs 66461-66462.
STEP 04

Turn overwrite into persistent manager access

Once the file lands, the attacker pivots to execution and persistence on the Manager node, then uses that position against the SD-WAN control plane. Talos observed multiple clusters deploying JSP shells and then issuing follow-on commands from those shells, which is exactly why a 'mere' file overwrite on a control-plane box matters more than the original 5.4 suggests.
Conditions required:
  • A useful payload path was written
  • The target serves or executes the planted content
  • The attacker can reach the management interface again to trigger it
Where this breaks in practice:
  • This is usually one host or cluster node at first, not automatic domain-wide compromise
  • Root is not guaranteed from CVE-2026-20122 alone
  • Well-monitored management zones can spot shell drops and odd post-exploit traffic quickly
Detection/coverage: Webshell hunting, file integrity monitoring on served JSP paths, and EDR/NDR on the management segment should catch much of the follow-on activity if those controls exist on the appliance tier.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusYes. Cisco updated the advisory on 2026-03-05 to say PSIRT was aware of active exploitation of CVE-2026-20122 and CVE-2026-20128; Talos later described widespread exploitation from March to April 2026.
KEV statusListed in CISA KEV on 2026-04-20 with a federal due date of 2026-04-23 per the NVD/CISA reference.
Proof-of-concept availabilityPublic PoC exists. Talos says exploitation surged after ZeroZenX Labs released PoC code in March 2026; Talos notes that PoC was commonly paired with the JSP shell it calls XenShell.
EPSSLow-to-moderate predictive score despite actual exploitation. CIRCL shows EPSS 0.01122 on 2026-05-05 with percentile 0.78347. That mismatch is the point: telemetry beat prediction here.
CVSS and interpretationThe CNA/NVD entry still shows 5.4 MEDIUM with CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, which models the standalone credentialed case. Cisco's later advisory text rates this specific issue High 7.1 with CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L, which better reflects file-write impact.
Affected versionsAffected trains are <20.9, 20.9 < 20.9.8.2, 20.10/20.11 < 20.12.6.1, 20.12 < 20.12.5.3 plus 20.12.6, 20.13-20.15 < 20.15.4.2, and 20.16-20.18 < 20.18.2.1.
Fixed versionsFirst fixed releases are 20.9.8.2, 20.12.5.3, 20.12.6.1, 20.15.4.2, and 20.18.2.1 depending on train. Older trains marked end-of-maintenance must migrate, not cherry-pick hope.
Exposure populationThis is not an internet-at-scale bug, but it is not niche either. VulnCheck reported roughly 275 internet-exposed instances via ZoomEye, 450-550 via Shodan/Censys, and 1000+ via FOFA around the disclosure window.
Disclosure and sourcePublished 2026-02-25. Cisco credits Arthur Vidineyev of the Cisco Advanced Security Initiatives Group (ASIG) for finding the issue during internal testing.
Detection coverageCisco published concrete IoCs in serviceproxy-access.log and a Check Bug Applicability Tool workflow for admin-tech review. Talos also published Snort SIDs 66461-66462 for CVE-2026-20122.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to HIGH (8.1/10)

The decisive factor is confirmed real-world exploitation on a high-value SD-WAN management plane, not the raw standalone CVSS math. This stays HIGH instead of CRITICAL because CVE-2026-20122 alone still requires authenticated API access or a companion-chain condition, which narrows the exposed population and means many victims are already partway through compromise before this bug matters.

HIGH Active exploitation / KEV status
HIGH Affected version and fixed-release mapping
MEDIUM How often CVE-2026-20122 is exploited standalone versus as part of the 20133+20128+20122 chain

Why this verdict

  • Active exploitation overrides comfort math: Cisco PSIRT, Talos, and CISA KEV all say this bug is not theoretical anymore.
  • Control-plane amplifier: compromise lands on SD-WAN Manager, a box with outsized operational blast radius compared with an ordinary app server.
  • Vendor baseline was too low for operations: starting from the original CNA 5.4 MEDIUM, I adjust upward for KEV listing, observed PoC-driven exploitation, and the fact that public-facing management nodes were actually being shelled.
  • But there is real friction: unauthenticated remote initial access is not what CVE-2026-20122 gives you by itself; it needs read-only API credentials or a successful chain.
  • Exposure is limited, not universal: hundreds of exposed nodes is serious for enterprise defenders, but it is nowhere near a mass-edge event affecting every VPN, browser, or mailbox.

Why not higher?

I am not calling this CRITICAL because the standalone exploit path is gated by PR:L and API access. In real terms, that means either prior compromise, credential theft, or successful chaining with other bugs; those are meaningful downward-pressure factors. Also, CVE-2026-20122 alone does not guarantee root or instant fabric-wide takeover.

Why not lower?

I am not leaving this at MEDIUM because defenders now have hard evidence that adversaries operationalized it and CISA put it in KEV. Once public PoC plus observed webshell deployment shows up on a management appliance, a paper-medium bug becomes a real patching priority.

05 · Compensating Control

What to do — in priority order.

  1. Remove internet exposure now — Put SD-WAN Manager behind a VPN, jump host, or strict allowlist immediately, within hours because KEV/active exploitation overrides the normal HIGH mitigation clock. This is the cleanest way to cut off the observed PoC-driven chain.
  2. Restrict API reachability — Allow only dedicated admin networks to hit the Manager API and block broad east-west access immediately, within hours. The bug lives on the API surface, so shrinking who can talk to it matters more than generic perimeter talking points.
  3. Review IoCs and admin-techs — Pull and inspect serviceproxy-access.log, compare source IPs to known admin activity, and run Cisco's Check Bug Applicability Tool workflow immediately, within hours. If you were exposed, assume the goal was shell placement, not just harmless probing.
  4. Rotate exposed service credentials — Rotate SD-WAN Manager admin/API credentials and any DCA-related secrets after containment immediately, within hours if there is any chance CVE-2026-20128 or this bug was touched. Credential reuse turns one box compromise into a cluster or cross-node problem.
  5. Deploy network detections — Push IDS/IPS coverage using Cisco Talos signatures and alert on the documented API paths within hours for exposed or suspected-exposed environments. This will not fix the bug, but it improves detection while you work through patching.
What doesn't work
  • MFA by itself does not neutralize this; CVE-2026-20122 abuses already-valid low-privilege API access, and the observed chain can manufacture that position through companion flaws.
  • A generic WAF rule in front of TCP/443 is not a dependable answer; this is product-specific API abuse on a management appliance, and many deployments have no real reverse-proxy normalization in front of it.
  • Credential rotation without reducing exposure is not enough if the host is still vulnerable and reachable; attackers can simply rerun the chain.
  • Waiting for routine quarterly patching is not defensible on a KEV-listed management-plane flaw with public PoC.
06 · Verification

Crowdsourced verification payload.

Run this on each Cisco Catalyst SD-WAN Manager node over SSH or console as an administrative user that can execute show system status or show version. Example: bash check_cve_2026_20122.sh or bash check_cve_2026_20122.sh 20.12.6. Root is not required if the CLI commands are available to your account.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_20122.sh
# Determine likely exposure to CVE-2026-20122 on Cisco Catalyst SD-WAN Manager.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

extract_version() {
  local input="$1"
  # Keep the first dotted numeric token, e.g. 20.12.6.1 or 20.7.0-185 -> 20.7.0
  echo "$input" | grep -Eo '[0-9]+(\.[0-9]+){1,3}' | head -n1
}

get_version() {
  if [[ $# -ge 1 && -n "${1:-}" ]]; then
    extract_version "$1"
    return 0
  fi

  local out ver

  if command -v show >/dev/null 2>&1; then
    out="$(show system status 2>/dev/null || true)"
    ver="$(echo "$out" | awk -F': *' '/^[[:space:]]*Version[[:space:]]*:/ {print $2; exit}')"
    ver="$(extract_version "$ver")"
    if [[ -n "$ver" ]]; then
      echo "$ver"
      return 0
    fi

    out="$(show version 2>/dev/null || true)"
    ver="$(extract_version "$out")"
    if [[ -n "$ver" ]]; then
      echo "$ver"
      return 0
    fi
  fi

  return 1
}

ver_to_sortkey() {
  local v="$1"
  local a b c d
  IFS='.' read -r a b c d <<< "$v"
  a=${a:-0}; b=${b:-0}; c=${c:-0}; d=${d:-0}
  printf '%03d%03d%03d%03d\n' "$a" "$b" "$c" "$d"
}

ver_lt() { [[ "$(ver_to_sortkey "$1")" < "$(ver_to_sortkey "$2")" ]]; }
ver_ge() { [[ "$(ver_to_sortkey "$1")" >= "$(ver_to_sortkey "$2")" ]]; }

VERSION="$(get_version "${1:-}")" || {
  echo "UNKNOWN - could not determine Cisco SD-WAN Manager version. Supply it explicitly, e.g.: bash $0 20.12.6"
  exit 2
}

if ! [[ "$VERSION" =~ ^[0-9]+\.[0-9]+(\.[0-9]+){0,2}$ ]]; then
  echo "UNKNOWN - unrecognized version format: $VERSION"
  exit 2
fi

IFS='.' read -r MAJ MIN PAT BUILD <<< "$VERSION"
PAT=${PAT:-0}
BUILD=${BUILD:-0}

# This script implements Cisco's fixed-release table for CVE-2026-20122.
# Vulnerable:
# - earlier than 20.9 -> migrate
# - 20.9.x < 20.9.8.2
# - 20.10.x and 20.11.x
# - 20.12.x < 20.12.5.3 plus exact 20.12.6
# - 20.13.x to 20.15.x < 20.15.4.2
# - 20.16.x to 20.18.x < 20.18.2.1

if [[ "$MAJ" -ne 20 ]]; then
  echo "UNKNOWN - this checker only knows Cisco's 20.x SD-WAN Manager release mapping; detected $VERSION"
  exit 2
fi

if (( MIN < 9 )); then
  echo "VULNERABLE - $VERSION is earlier than 20.9 and must migrate to a fixed release"
  exit 1
fi

if (( MIN == 9 )); then
  if ver_lt "$VERSION" "20.9.8.2"; then
    echo "VULNERABLE - $VERSION is below 20.9.8.2"
    exit 1
  else
    echo "PATCHED - $VERSION is at or above 20.9.8.2"
    exit 0
  fi
fi

if (( MIN == 10 || MIN == 11 )); then
  echo "VULNERABLE - $VERSION must move to 20.12.6.1 or later per Cisco fixed-release guidance"
  exit 1
fi

if (( MIN == 12 )); then
  if [[ "$VERSION" == "20.12.6" ]]; then
    echo "VULNERABLE - 20.12.6 is explicitly affected; move to 20.12.6.1 or later"
    exit 1
  fi
  if ver_lt "$VERSION" "20.12.5.3"; then
    echo "VULNERABLE - $VERSION is below 20.12.5.3"
    exit 1
  fi
  if ver_ge "$VERSION" "20.12.6.1"; then
    echo "PATCHED - $VERSION is at or above 20.12.6.1"
    exit 0
  fi
  echo "PATCHED - $VERSION appears to be in the fixed 20.12.x range"
  exit 0
fi

if (( MIN >= 13 && MIN <= 15 )); then
  if ver_lt "$VERSION" "20.15.4.2"; then
    echo "VULNERABLE - $VERSION is below 20.15.4.2"
    exit 1
  else
    echo "PATCHED - $VERSION is at or above 20.15.4.2"
    exit 0
  fi
fi

if (( MIN >= 16 && MIN <= 18 )); then
  if ver_lt "$VERSION" "20.18.2.1"; then
    echo "VULNERABLE - $VERSION is below 20.18.2.1"
    exit 1
  else
    echo "PATCHED - $VERSION is at or above 20.18.2.1"
    exit 0
  fi
fi

echo "PATCHED - $VERSION is newer than the affected trains covered by Cisco's advisory"
exit 0
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat exposed or broadly reachable SD-WAN Manager as an active incident surface: remove public/API exposure, review Cisco IoCs, and validate version on every node immediately, within hours, because KEV/active exploitation overrides the normal noisgate mitigation SLA for a HIGH finding. For actual remediation, drive all vulnerable trains to Cisco's fixed releases and finish the patch program within 180 days under the noisgate remediation SLA, but do the internet-facing and suspected-compromised managers first, not last.

Sources

  1. Cisco security advisory: Cisco Catalyst SD-WAN Vulnerabilities
  2. NVD entry for CVE-2026-20122
  3. Cisco Talos: Ongoing exploitation of Cisco Catalyst SD-WAN vulnerabilities
  4. Cisco: Verify SD-WAN PSIRT with the Check Bug Applicability Tool
  5. CISA Known Exploited Vulnerabilities Catalog query
  6. VulnCheck exposure analysis for Cisco SD-WAN Manager
  7. CIRCL Vulnerability-Lookup for CVE-2026-20122
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.