Cisco Catalyst SD-WAN Manager Arbitrary File Write Vulnerability

CVE-2026-20262 is an authenticated arbitrary file write in the Cisco Catalyst SD-WAN Manager web UI caused by improper validation during file upload. Cisco says a remote attacker with valid credentials and at least *write* access can create or overwrite files anywhere on the underlying filesystem, and that overwritten file can later be used to elevate to root. Cisco marks all deployment types as affected regardless of configuration, with fixes in 20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1, and 26.1.1.2.

The vendor's 6.5 MEDIUM underrates the real enterprise problem. Yes, the chain requires authenticated remote access, which normally pushes severity down; but this is the centralized SD-WAN management plane, Cisco says exploitation is already happening, and CISA added it to KEV on 2026-06-15. On a platform that can push policy and orchestrate connectivity across the WAN fabric, a post-auth file-write-to-root chain is a control-plane compromise, not a mere integrity bug.

Why this verdict

• Start from vendor MEDIUM, then apply the friction audit: PR:L means this is not a one-packet unauthenticated internet bug. That would normally hold the score near the vendor's 6.5, because the attacker position is *authenticated remote*, which implies either prior credential theft, prior foothold, or abuse by an insider/admin-adjacent user.
• Exposure is narrowed, but not niche: Cisco warns internet-exposed managers are at risk, and product-level exposure data still shows hundreds of reachable SD-WAN deployments in Shodan/Censys class search engines. So while this is not wormable at internet scale, the reachable population is well above the '<1%' comfort zone defenders sometimes use to justify a deep downgrade.
• Active exploitation changes the math: Cisco says exploitation is already happening, and CISA KEV added the CVE on 2026-06-15. That means the chain is not hypothetical; some actor already solved the practical friction and found the post-auth path worthwhile.
• Modern controls only partially help: MFA, IdP protections, VPN gating, and IP allowlists can stop step 1. They do not stop the exploit once the attacker has a valid session with write access, and there is no Cisco workaround that neutralizes the vulnerable code path.
• Role multiplier: On a low-value role such as a lab or isolated test manager, the documented chain still succeeds, but the blast radius is mostly host or small tenant impact. On a typical production member deployment managing real branch fabrics, root on SD-WAN Manager becomes tenant/fleet impact because the product is trusted to push templates, policy, and orchestration state. On the high-value role that actually defines this product — the centralized enterprise SD-WAN control plane — the same chain plausibly ends in fleet compromise / mass network-policy tampering, so the verdict floor is CRITICAL.

Why not higher?

This is not a 10.0 unauthenticated takeover. The attacker needs valid credentials with write-capable access, and not every arbitrary file write target produces immediate root without choosing a useful path such as a deployable artifact or trusted config. Cisco also describes exploitation as *limited*, which argues against a maximal spray-and-pray score.

Why not lower?

A downgrade to HIGH or MEDIUM would over-focus on PR:L and ignore where the bug lives. This is the SD-WAN management plane, not a random line-of-business web app, and KEV confirms that real attackers are already cashing in that role value. Once root lands here, you are defending the fabric, not a single node.

1. Restrict management-plane reachability now — Immediately, within hours, place every SD-WAN Manager behind VPN, jump host, and strict source-IP allowlists if it is reachable from untrusted networks. This is the highest-value containment move because it directly attacks the authenticated-remote prerequisite while you execute patching; for a CRITICAL issue, do not wait past the ≤ 3 days control window, and because this is KEV-listed/actively exploited, treat it as same-day containment.
2. Clamp down write-capable accounts — Immediately review and temporarily reduce the population of accounts that have the write access needed for exploitation. Disable stale local users, rotate passwords and API tokens, verify SSO group mappings, and force re-authentication for privileged sessions; do this within hours because the decisive downgrade friction is credentials, so removing or shrinking that credential surface matters fast.
3. Hunt Cisco's upload and deployment IoCs — Within 24 hours, review /var/log/nms/vmanage-server.log, /var/log/nms/vmanage-appserver.log, and serviceproxy-access.log for suspicious WAR uploads, WildFly deployment events, and unexpected POSTs to newly deployed paths. Cisco provided concrete examples, so use them for environment-specific matching and escalate any hit as a likely compromise until disproven.
4. Instrument host and change-plane detection — Within 3 days, ensure the manager has host telemetry or equivalent audit visibility for process execution, service changes, and file writes under deployment directories, then pair that with SD-WAN audit monitoring for abnormal template/policy activity. The point is to catch the transition from file-write foothold to control-plane abuse before it becomes fabric-wide damage.

Run this on an admin workstation or directly on the SD-WAN Manager shell after you determine the node's software version. A practical workflow is: SSH to the node, run request nms application-server version, then execute ./check_cve_2026_20262.sh 20.12.7.1; no root is required for the script itself, but you need whatever privileges are necessary to retrieve the appliance version.

#!/usr/bin/env bash
# check_cve_2026_20262.sh
# Determine whether a Cisco Catalyst SD-WAN Manager version is vulnerable to CVE-2026-20262.
#
# Usage:
#   ./check_cve_2026_20262.sh <version>
# Example:
#   ./check_cve_2026_20262.sh 20.12.7.1
#
# Output:
#   VULNERABLE
#   PATCHED
#   UNKNOWN
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / bad input

set -u

ver="${1:-}"
if [[ -z "$ver" ]]; then
  echo "UNKNOWN"
  exit 2
fi

if ! [[ "$ver" =~ ^[0-9]+(\.[0-9]+){1,3}$ ]]; then
  echo "UNKNOWN"
  exit 2
fi

version_le() {
  # returns 0 if $1 <= $2
  local a b IFS=.
  read -r -a a <<< "$1"
  read -r -a b <<< "$2"
  local len=${#a[@]}
  (( ${#b[@]} > len )) && len=${#b[@]}
  for ((i=0; i<len; i++)); do
    local ai=${a[i]:-0}
    local bi=${b[i]:-0}
    if (( ai < bi )); then return 0; fi
    if (( ai > bi )); then return 1; fi
  done
  return 0
}

version_ge() {
  # returns 0 if $1 >= $2
  version_le "$2" "$1"
}

major_minor() {
  local IFS=.
  read -r a b _ <<< "$1"
  echo "$a.$b"
}

mm="$(major_minor "$ver")"

# Cisco fixed-release map from advisory:
# 20.9.9.1 and earlier   -> fixed in 20.9.9.2
# 20.12.7.1 and earlier  -> fixed in 20.12.7.2
# 20.15.4.4 and earlier  -> fixed in 20.15.4.5
# 20.15.5.2 and earlier  -> fixed in 20.15.5.3
# 20.18.3                -> fixed in 20.18.3.1
# 26.1.1.1 and earlier   -> fixed in 26.1.1.2
# NVD ranges also indicate affected trains spanning 20.10.x, 20.11.x, 20.13.x, 20.14.x, 20.16.x, 20.17.x.

case "$mm" in
  20.9)
    if version_le "$ver" "20.9.9.1"; then echo "VULNERABLE"; exit 1; else echo "PATCHED"; exit 0; fi
    ;;
  20.10|20.11)
    echo "VULNERABLE"
    exit 1
    ;;
  20.12)
    if version_le "$ver" "20.12.7.1"; then echo "VULNERABLE"; exit 1; else echo "PATCHED"; exit 0; fi
    ;;
  20.13|20.14)
    echo "VULNERABLE"
    exit 1
    ;;
  20.15)
    if version_ge "$ver" "20.15.5"; then
      if version_le "$ver" "20.15.5.2"; then echo "VULNERABLE"; exit 1; else echo "PATCHED"; exit 0; fi
    else
      if version_le "$ver" "20.15.4.4"; then echo "VULNERABLE"; exit 1; else echo "PATCHED"; exit 0; fi
    fi
    ;;
  20.16|20.17)
    echo "VULNERABLE"
    exit 1
    ;;
  20.18)
    if version_le "$ver" "20.18.3"; then echo "VULNERABLE"; exit 1; else echo "PATCHED"; exit 0; fi
    ;;
  26.1)
    if version_le "$ver" "26.1.1.1"; then echo "VULNERABLE"; exit 1; else echo "PATCHED"; exit 0; fi
    ;;
  *)
    # Unknown/newer train not explicitly documented in the advisory.
    echo "UNKNOWN"
    exit 2
    ;;
esac

Sources

1. Cisco advisory for CVE-2026-20262
2. CISA KEV catalog entry
3. FIRST EPSS lookup
4. CIRCL vulnerability lookup metadata for CVE-2026-20262
5. VulnCheck exposure analysis for Cisco Catalyst SD-WAN
6. Help Net Security coverage of the exploited flaw
7. SecurityWeek coverage of Cisco's advisory