CVE-2026-76504

What is Cisco Catalyst SD-WAN Manager?

Cisco Catalyst SD-WAN Manager, formerly vManage and before that Viptela vManage, is the centralized management and orchestration plane for Cisco's SD-WAN fabric. A single Manager instance defines routing policy, segmentation, templates, certificates and device configuration for every edge router in the overlay, and it exposes a REST API that automation pipelines and NMS integrations drive directly.

That concentration is exactly what makes it attractive to an attacker. Administrative control of the Manager is not control of one appliance, it is control of the WAN: an attacker who reaches admin can push configuration to branch routers, alter traffic steering or segmentation, extract device credentials and certificates, and establish a persistent foothold that survives at the fabric level rather than on any one host.

Overview

CVE-2026-76504 is an authentication bypass in the API session management of Catalyst SD-WAN Manager. An unauthenticated, remote attacker who can reach the web management interface can send a crafted HTTP request that slips past the authentication rule protecting the login endpoint and ends up interacting with the API as the built-in admin user. No credentials, no user interaction, and no particular configuration are required, which is what produces the CVSS 3.1 base score of 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Cisco disclosed the flaw on 2026-09-30 in advisory cisco-sa-sdwan-webauth-xr8beuuU and stated that its Product Security Incident Response Team was already aware of exploitation attempts in the wild. This was a zero-day: attacks preceded the patch. CISA added the CVE to the Known Exploited Vulnerabilities catalog the same day with an unusually short remediation deadline of 2026-10-03, and the entry carries the newer BOD 26-04 required-action language rather than the older BOD 22-01 wording.

Cisco has published no workaround. The only fixes are the patched releases listed below, plus hardening that keeps the management interface off the public internet.

Affected Versions

Technical Details

The root cause is CWE-177, improper handling of URL encoding, specifically hex encoding. In plain terms: two parts of the request pipeline disagree about what the URL says. The front-end authentication rule matches request paths as literal strings, so it protects /j_security_check, the classic Java servlet form-login endpoint inherited from the platform's Tomcat lineage. The request router further down the stack percent-decodes the path before dispatching it. An attacker who writes the leading j as its hex escape %6a produces a path such as /%6a_security_check, which the authentication rule does not recognise as the protected endpoint and therefore passes through, but which the router decodes back to j_security_check and handles as a valid login-session request.

The gap between those two views of the same URL is the whole vulnerability. Decoding is done inconsistently and the path is never canonicalised before the authorization decision is made, so the session-validation step for that API route is simply skipped. The result is a request that reaches authenticated API surface while carrying no session at all, and the server services it with the privileges of admin, which in Catalyst SD-WAN maps to the netadmin role and all device operations.

Attack characteristics are as bad as they get: network reachable, low complexity, no authentication, no user interaction, and no chaining needed. A single crafted HTTP request is enough. Because the payload is an ordinary encoded path rather than an injected script or binary, generic WAF signatures are unlikely to catch it without a rule written specifically for encoded variants of this endpoint.

Discovery

Cisco credits no external researcher. Per the advisory, the flaw was identified internally during the resolution of a Cisco Technical Assistance Center support case, which is the usual phrasing for a bug surfaced while investigating a customer incident. That sequence is consistent with in-the-wild exploitation being discovered first and the underlying vulnerability second. Cisco has not named the affected customer or the date the case was opened. A public proof-of-concept appeared on GitHub shortly after disclosure, so the technique is no longer restricted to whoever found it first.

Exploitation Context

Cisco confirms active exploitation but has released very little detail: the advisory does not say how many customers were attacked, when the campaign began, who conducted it, or what the attackers did after gaining admin. No threat-actor attribution has been published, and CISA's KEV entry records no known ransomware use. There is no evidence of chaining with another CVE; none is needed.

Internet-scan data gives the exposed population as roughly 450 to 550 publicly reachable Catalyst SD-WAN Manager instances, a small number in absolute terms but a high-value one given what each instance controls. This is the latest in a run of Catalyst SD-WAN Manager authentication flaws through 2026, following CVE-2026-20182 in May and CVE-2026-20245 and CVE-2026-20262 in June, which suggests sustained attacker interest in this attack surface.

Cisco published concrete indicators of compromise. Two artifacts are worth hunting for immediately:

• Requests containing hex-encoded variants of the login path, for example POST /%6a_security_check, from unfamiliar source addresses, in /var/log/nms/containers/service-proxy/serviceproxy-access.log.
• Authentication or account activity for usernames beginning with viptela-reserved- in /var/log/nms/vmanage-server.log, which indicates the attacker reached account operations.

Remediation

1. Upgrade to a fixed release now, outside the normal maintenance cycle: 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1 or 26.2.1. Deployments on releases earlier than 20.9 have no fix and must migrate to a supported train.
2. If you run Cisco-hosted Catalyst SD-WAN Manager, confirm your instance is on 20.15.605 or later; Cisco applies this fix, but verify rather than assume.
3. There is no workaround. Do not treat any filtering rule as a substitute for the patch.
4. Remove the management interface from the public internet. Restrict access to the Manager web UI and API to known trusted management hosts, and place control components behind a firewall or VPN.
5. Hunt for compromise even after patching, since exploitation preceded the fix. Search serviceproxy-access.log for encoded j_security_check paths and vmanage-server.log for viptela-reserved- usernames, and review admin API activity from unfamiliar addresses.
6. If you find indicators, treat the whole fabric as suspect: audit user accounts, API tokens, device templates and policy changes, rotate credentials and certificates, and compare the running configuration against a known-good baseline.
7. Federal civilian agencies must remediate by 2026-10-03 under the KEV entry's required action, which follows BOD 26-04. Everyone else should treat that date as the realistic window before commodity exploitation, given the public proof-of-concept.