← Back to Feed CACHED · 2026-10-01 08:16:22 · CACHE_KEY CVE-2026-20262
CVE-2026-20262 · CWE-22 · Disclosed 2026-06-15

Cisco Catalyst SD-WAN Manager Path Traversal Arbitrary File Write to Root

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

This is like finding a skeleton key to the building's master control room and the landlord calling it a sticky lock

CVE-2026-20262 is a path-traversal flaw (CWE-22) in the web UI file-upload API of Cisco Catalyst SD-WAN Manager (formerly vManage). An authenticated attacker with at least write-level access sends a crafted HTTP POST containing ../ sequences to place or overwrite arbitrary files on the underlying Linux filesystem. The documented weaponization path drops a malicious .war file into WildFly's auto-deployment directory (/var/lib/wildfly/standalone/deployments/), which the application server picks up and executes — giving the attacker a webshell that escalates to root. Every supported release train is affected: 20.9.x through 26.1.x across on-prem, Cloud-Pro, Cloud-Managed, and FedRAMP deployments. Fixed releases are 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.

Cisco rated this MEDIUM 6.5 based on a narrow CVSS vector that captures only I:H — integrity impact to the file system — and credits the authentication requirement (PR:L) as a significant brake. That rating is dangerously misleading. The CVSS vector ignores the root escalation that follows the file write, ignores the blast radius of owning the SD-WAN orchestrator (which pushes config, certs, and firmware to every managed edge device), and ignores the fact that CISA added it to KEV on June 15, 2026 after confirming active exploitation. Cisco's own PSIRT described the campaign as 'a highly targeted operation by a sophisticated threat actor.' When the management plane of your entire WAN fabric can be rooted by a low-privileged user with a single HTTP request, MEDIUM is the wrong word.

"Vendor says MEDIUM 6.5 but root on SD-WAN Manager means fleet-scale WAN takeover — treat as CRITICAL."
02 · The Attack Path

6 steps from start to impact.

STEP 01

Obtain SD-WAN Manager credentials

The attacker acquires valid credentials with write-level access to the SD-WAN Manager web UI. In observed campaigns this has been accomplished via credential stuffing, phishing of network administrators, or — more critically — chaining with CVE-2026-20182, a CVSS 10.0 authentication bypass on the same product disclosed weeks earlier. The bar for 'authenticated' is lower than the CVSS suggests when the same product line has an active auth-bypass zero-day.
Conditions required:
  • Valid SD-WAN Manager credentials with write access OR ability to chain CVE-2026-20182 auth bypass
Where this breaks in practice:
  • Authentication is a real gate — without credentials or a chain, the attack stops here
  • SD-WAN Manager admin accounts are typically limited to network operations staff
Detection/coverage: Failed login attempts visible in vmanage-server.log; anomalous session creation detectable via SIEM correlation on SD-WAN Manager auth events
STEP 02

Access the SD-WAN Manager web UI

The attacker reaches the vManage web interface over HTTPS (port 8443 or 443). Censys data shows ~450–550 instances directly exposed to the internet, but the far larger population is reachable from internal management VLANs. Any post-initial-access position on the corporate network — e.g., via VPN compromise, phishing, or lateral movement — puts the management plane in reach.
Conditions required:
  • Network path to SD-WAN Manager web UI (internet or internal management VLAN)
Where this breaks in practice:
  • Internet-exposed population is small (~500 globally per Censys)
  • Well-segmented environments restrict management-plane access to jump hosts
Detection/coverage: GreyNoise and Shodan track exposed vManage instances; internal exposure auditable via Nmap scan of 8443/tcp on management subnets
STEP 03

Send crafted file-upload request with path traversal

The attacker sends a POST request to the vulnerable file-upload API endpoint with a filename containing ../../../../var/lib/wildfly/standalone/deployments/malicious.war. The application fails to canonicalize the path, allowing the attacker to write the WAR file outside the intended upload directory. No special tooling is required — curl or any HTTP client suffices. At least 2 public PoC repositories (fevar54 and others indexed by Exploit Intelligence Platform) automate this step.
Conditions required:
  • Authenticated session from Step 1
  • Knowledge of WildFly deployment path (publicly documented)
Where this breaks in practice:
  • Web application firewalls (WAFs) with path-traversal signatures may block ../ sequences in multipart uploads
  • Cisco hardened some upload endpoints in earlier releases, but the specific endpoint remains vulnerable
Detection/coverage: Monitor vmanage-server.log for upload attempts containing ../ sequences or .war/.jsp filenames; Nuclei template available for unauthenticated detection of vulnerable versions
STEP 04

WildFly auto-deploys malicious WAR → webshell

WildFly's deployment scanner detects the new .war file and automatically deploys it. The attacker now has a webshell running with the privileges of the WildFly application server process. Observed IOCs include index.jsp and custom WAR payloads visible in serviceproxy-access logs. This step is fully automated — no additional attacker interaction required after the upload.
Conditions required:
  • WildFly deployment scanner is enabled (default configuration)
Where this breaks in practice:
  • None — WildFly auto-deployment is on by default in SD-WAN Manager
Detection/coverage: Check /var/lib/wildfly/standalone/deployments/ for unexpected .war files; monitor vmanage-appserver and serviceproxy-access logs for POST requests to unknown servlet paths
STEP 05

Escalate to root on the SD-WAN Manager appliance

From the webshell, the attacker escalates privileges to root. The SD-WAN Manager appliance runs a constrained Linux environment where the WildFly process has access to sensitive configuration files, JWT signing keys, and local privilege escalation paths. Cisco confirmed that the file-write primitive is sufficient to 'elevate to root.' Observed campaigns extracted AWS credentials and JWT keys from the appliance.
Conditions required:
  • Webshell execution from Step 4
Where this breaks in practice:
  • Minimal — the appliance OS is not hardened against local privesc from the application service account
Detection/coverage: Host-based monitoring for unexpected process trees spawned by WildFly; file-integrity monitoring on /etc/, /root/, and WildFly deployment directories
STEP 06

Pivot to managed SD-WAN fabric

With root on the SD-WAN Manager, the attacker controls the management plane for the entire SD-WAN fabric. This includes the ability to push configuration templates to all managed edge routers, modify routing policies, exfiltrate device certificates, deploy firmware updates containing backdoors, and intercept or redirect WAN traffic. The blast radius is every SD-WAN edge device under management — potentially hundreds or thousands of branch routers. This is the 'vCenter moment' for the WAN.
Conditions required:
  • Root access on SD-WAN Manager from Step 5
Where this breaks in practice:
  • None — this is the designed function of the management plane
Detection/coverage: SD-WAN edge devices log configuration pushes; compare running configs against known-good baselines; monitor for unexpected certificate reissuance or firmware push events
03 · Compensating Control

1
CRITICAL 9.1→HIGH 7.5
SEVERITY REDUCED
Restrict SD-WAN Manager web UI to dedicated jump hosts via ACL — Deploy firewall rules or infrastructure ACLs limiting HTTPS access (ports 443/8443) to the SD-WAN Manager web UI to a small set of hardened jump hosts on a dedicated management VLAN. This eliminates the network-access prerequisite for both internet-based and lateral-movement-based attackers. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings. This breaks the attack path at Step 2 — the attacker cannot reach the vulnerable API endpoint.
2
CRITICAL 9.1→HIGH 7.0
SEVERITY REDUCED
Enforce MFA on all SD-WAN Manager user accounts — Enable multi-factor authentication for every account with write access to vManage, preferably via SAML/SSO integration with your IdP. This raises the bar on Step 1 — stolen passwords alone are insufficient. If MFA is already enforced, audit for service accounts or API tokens that bypass it. Deploy within 3 days.
3
CRITICAL 9.1→HIGH 7.5
SEVERITY REDUCED
Audit and disable unnecessary write-level user accounts — Review all SD-WAN Manager local and RADIUS/TACACS+ accounts. Disable or downgrade any account with write access that does not require it for current operations. The vulnerability requires write-level access — read-only accounts cannot exploit it. Reduces the credential surface for Step 1. Complete within 3 days.
4
CRITICAL 9.1→CRITICAL 9.1
Monitor vmanage-server.log for path-traversal IOCs — Deploy a SIEM rule or log-forwarding configuration to alert on entries in /var/log/nms/vmanage-server.log matching ../ sequences, unexpected .war or .jsp filenames, and POST requests to unknown servlet paths in serviceproxy-access logs. This provides detection for Steps 3–4 and enables rapid incident response. Does not prevent exploitation but dramatically reduces dwell time. Deploy within 3 days.
5
CRITICAL 9.1→IGNORE 0.0
SEVERITY REDUCED
Apply the vendor patch immediately — Upgrade to the fixed release for your train: 20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1, or 26.1.1.2. This is the only control that fully eliminates the vulnerability. Given KEV listing and active exploitation, treat the noisgate remediation SLA of 90 days as an outer bound — actual patching should occur within days, not weeks. The CISA federal deadline was 2026-06-29.
What doesn't work
  • Disabling WildFly deployment scanner — while this would prevent auto-deployment of the dropped WAR file (breaking Step 4), it is not a supported configuration change on SD-WAN Manager and will break legitimate application functionality including software upgrades and plugin management.
  • WAF with generic path-traversal rules in front of vManage — SD-WAN Manager uses its own embedded web server and TLS termination; inserting a reverse proxy or WAF in front of it is not a supported topology and may break cluster communication, certificate validation, and REST API functionality.
  • Network segmentation of edge devices from the manager — SD-WAN Manager requires continuous connectivity to all managed edges for control-plane operations. Isolating the manager from the fabric defeats the product's purpose and is not a viable compensating control.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationConfirmed active. Cisco PSIRT acknowledged 'limited exploitation' in June 2026. CISA added to KEV on 2026-06-15 with a federal remediation deadline of 2026-06-29. Cisco described it as 'a highly targeted operation by a sophisticated threat actor.' The broader SD-WAN campaign involves UAT-8616, an APT tracked by Talos exploiting multiple SD-WAN CVEs with ORB network infrastructure.
Proof-of-concept availabilityAt least 2 public PoC repositories indexed by Exploit Intelligence Platform (EIP), including work by GitHub user fevar54. The exploit is trivial — a single curl POST with path-traversal in the filename field. No Metasploit module yet, but the low complexity means weaponization is straightforward. Nuclei template exists for version detection (CVE-2026-2262.yaml in projectdiscovery/nuclei-templates, note: numbering discrepancy — verify applicability).
EPSS score28.17% probability of exploitation in 30 days (98th percentile). This places it in the top 2% of all scored CVEs — consistent with confirmed active exploitation and available PoCs.
CISA KEV statusListed. Added 2026-06-15. Federal remediation deadline: 2026-06-29. Not currently associated with known ransomware campaigns per CISA's catalog. BOD 26-04 applies.
CVSS vector interpretationCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N — Network-accessible, low complexity, low-privilege auth required, no user interaction. The vector only captures the file-write impact (I:H) and entirely misses the root escalation and downstream fabric compromise. A more accurate post-exploitation assessment would be C:H/I:H/A:H with S:C (changed scope — impact extends to managed edge devices).
Affected version rangesAll Catalyst SD-WAN Manager releases: 20.9.9.1 and earlier, 20.12.7.1 and earlier, 20.15.4.4 and earlier, 20.15.5.2 and earlier, 20.18.3, 26.1.1.1 and earlier. Affects on-prem, Cloud-Pro, Cloud (Cisco Managed), and FedRAMP deployments.
Fixed versions20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1, 26.1.1.2. Patches released 2026-06-15. Same fix addresses sibling CVE-2026-20245.
Internet exposure~450–550 instances publicly reachable per Censys scans. Small internet footprint, but the internal management-network population is orders of magnitude larger. SD-WAN Manager is present in every Cisco SD-WAN deployment by definition.
Disclosure timelineDisclosed and patched 2026-06-15 as a zero-day with confirmed exploitation. Cisco discovered the exploitation during internal security monitoring. CISA KEV addition same day. This is the eighth actively exploited Cisco SD-WAN flaw in 2026.
Campaign contextPart of a sustained campaign against Cisco SD-WAN infrastructure. Talos tracks the primary actor as UAT-8616, deploying Nim backdoors, Sliver C2, AdaptixC2, gsocket tunnels, XenShell/Godzilla/Behinder webshells, XMRig miners, and credential-harvesting scripts. Ten distinct threat clusters observed exploiting related SD-WAN CVEs (CVE-2026-20182, CVE-2026-20133, CVE-2026-20128, CVE-2026-20122).

Sources.

  1. Cisco Security Advisory — Catalyst SD-WAN Manager Arbitrary File Write
  2. CISA KEV Catalog Entry — CVE-2026-20262
  3. BleepingComputer — Cisco fixes SD-WAN vManage flaw exploited in zero-day attacks
  4. The Hacker News — Cisco Releases Security Updates for Actively Exploited SD-WAN Manager Flaw
  5. Help Net Security — Cisco discloses second exploited SD-WAN vulnerability
  6. SecurityAffairs — CVE-2026-20262 Under Active Targeted Exploitation
  7. Talos Intelligence — Ongoing exploitation of Cisco Catalyst SD-WAN vulnerabilities
  8. SOCRadar — CVE-2026-20262: Cisco Catalyst SD-WAN Manager Zero-Day Leads to Root
05 · The Call

Final Verdict
↑ UPGRADED to CRITICAL (9.1/10)

Why this verdict

  • Active exploitation overrides paper severity. CISA KEV-listed with confirmed in-the-wild exploitation by a sophisticated APT (UAT-8616 cluster). EPSS at 98th percentile. The vendor's MEDIUM 6.5 is a measurement of the file-write primitive in isolation — not the realized attack chain that ends in root.
  • CVSS vector is structurally incomplete. The vendor vector scores only I:H (integrity) with C:N/A:N, capturing the file write but ignoring the root escalation, credential theft (C:H), service disruption (A:H), and the scope change to managed edge devices (S:C). A chain-aware rescoring yields approximately 9.1.
  • Authentication friction is real but proven surmountable. PR:L requires write-level credentials — a meaningful gate in theory. In practice: (a) active exploitation confirms attackers are clearing this bar, (b) CVE-2026-20182 (CVSS 10.0 auth bypass on the same product, also KEV-listed) eliminates the auth requirement entirely when chained, (c) credential reuse and phishing of network admin accounts are well-documented initial access vectors for this campaign.
  • Internet exposure is limited (~500 instances) but internal exposure is universal. The small Censys footprint reduces mass-exploitation risk from the internet, but any internal network position puts SD-WAN Manager in reach. Post-initial-access attackers (which is what UAT-8616 is) face no network friction.
  • Role multiplier: SD-WAN Manager is canonically a fleet-scale management plane. 100% of Cisco Catalyst SD-WAN Manager instances ARE the orchestration layer for the SD-WAN fabric — this is not a workstation role or a dev sandbox. Root on SD-WAN Manager grants the attacker the ability to push arbitrary configurations, certificates, and firmware to every managed edge router. The blast radius is fleet-scale (potentially hundreds to thousands of WAN edge devices per deployment). This meets the CRITICAL floor: the component is canonically high-value (≥10% — in fact 100% — of installs occupy the network-orchestration high-value role), and the documented chain succeeds with a fleet-compromise outcome.
  • Chain potential with sibling CVEs amplifies urgency. This is the eighth exploited SD-WAN flaw in 2026. The same threat actors are chaining multiple CVEs (auth bypass + file write + privesc). Patching CVE-2026-20262 in isolation while leaving CVE-2026-20182 unpatched provides no protection.

Why not higher?

A score above 9.1 would imply unauthenticated, zero-click, wormable exploitation. CVE-2026-20262 still requires authentication (PR:L) as a standalone vulnerability, and the internet-exposed population is small (~500 instances). While chainable with CVE-2026-20182 for unauthenticated access, the chain requires two distinct vulnerabilities — the file-write alone is not a 10.0.

Why not lower?

Downgrading below CRITICAL would require ignoring three hard facts: (1) active exploitation is confirmed and KEV-listed, (2) the affected component is the management plane for the entire SD-WAN fabric with fleet-scale blast radius by design, and (3) public PoCs exist with EPSS at 98th percentile. The authentication requirement, while real, is demonstrably insufficient to prevent exploitation — the attackers are already inside. A generic 'requires credentials' statement does not break the CRITICAL floor when the credential barrier has been cleared in observed campaigns.

06 · Verification

Crowdsourced verification payload.

Run this script on the Cisco Catalyst SD-WAN Manager appliance as root or the admin user via SSH. Usage: bash check_cve_2026_20262.sh. It checks the installed software version against known-fixed releases and scans logs for exploitation IOCs. Exit code 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-20262 Checker — Cisco Catalyst SD-WAN Manager
# Checks installed version and scans for exploitation IOCs.
# Run on the vManage appliance as root/admin.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -uo pipefail

RESULT="UNKNOWN"
IOC_FOUND=0

# --- Determine installed version ---
VERSION=""
if [ -f /usr/share/viptela/version ]; then
    VERSION=$(head -1 /usr/share/viptela/version | tr -d '[:space:]')
elif [ -f /etc/viptela/version ]; then
    VERSION=$(head -1 /etc/viptela/version | tr -d '[:space:]')
else
    # Fallback: parse 'show software' output if available
    VERSION=$(vmanage 2>/dev/null <<< 'show software' | awk '/true/{print $1; exit}')
fi

if [ -z "$VERSION" ]; then
    echo "[!] Could not determine SD-WAN Manager version."
    echo "    Run 'show software' from the vManage CLI and compare manually."
    echo "STATUS: UNKNOWN"
    exit 2
fi

echo "[*] Detected version: $VERSION"

# --- Version comparison (sort -V based) ---
ver_gte() { [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" = "$2" ]; }

# --- Check against fixed releases ---
case "$VERSION" in
    20.9.*)
        ver_gte "$VERSION" "20.9.9.2" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
    20.12.*)
        ver_gte "$VERSION" "20.12.7.2" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
    20.15.4.*)
        ver_gte "$VERSION" "20.15.4.5" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
    20.15.5.*)
        ver_gte "$VERSION" "20.15.5.3" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
    20.15.*)
        RESULT="VULNERABLE" ;;
    20.18.*)
        ver_gte "$VERSION" "20.18.3.1" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
    26.*)
        ver_gte "$VERSION" "26.1.1.2" && RESULT="PATCHED" || RESULT="VULNERABLE" ;;
    *)
        echo "[!] Version $VERSION not in a known affected release train."
        RESULT="UNKNOWN" ;;
esac

# --- IOC scan in logs ---
LOG_DIR="/var/log/nms"
echo ""
echo "[*] Scanning logs for exploitation IOCs..."
if [ -d "$LOG_DIR" ]; then
    # Path-traversal patterns in upload requests
    if grep -rlE '\.\.(/|%2[fF]){2,}.*\.(war|jsp|sh)' "$LOG_DIR"/vmanage-server*.log 2>/dev/null; then
        echo "[!] WARNING: Path-traversal upload IOC detected!"
        IOC_FOUND=1
    fi
    # Unexpected WAR deployments
    if ls /var/lib/wildfly/standalone/deployments/*.war 2>/dev/null | grep -qvE '(vmanage|nms|portal)'; then
        echo "[!] WARNING: Unexpected WAR file in WildFly deployments!"
        ls /var/lib/wildfly/standalone/deployments/*.war 2>/dev/null
        IOC_FOUND=1
    fi
    if [ "$IOC_FOUND" -eq 0 ]; then
        echo "[*] No IOC patterns found in available logs."
    fi
else
    echo "[!] Log directory $LOG_DIR not found — skipping IOC check."
fi

echo ""
if [ "$IOC_FOUND" -eq 1 ]; then
    echo "[!!!] EXPLOITATION IOCs DETECTED — initiate incident response."
fi
echo "STATUS: $RESULT"

case "$RESULT" in
    VULNERABLE) exit 1 ;;
    PATCHED)    exit 0 ;;
    *)          exit 2 ;;
esac