CVSS 9.8 authentication bypass in Cisco Catalyst SD-WAN Manager under active exploitation

Cisco has disclosed CVE-2026-76504, a critical vulnerability in Catalyst SD-WAN Manager that allows a remote attacker with no credentials to obtain administrator-level API access by sending a single crafted HTTP request, according to a dev.to analysis. The flaw is rated CVSS 3.1 9.8, has no workarounds, and — per the write-up — was already being exploited in the wild before Cisco's September 30, 2026 advisory was published.

How the bypass works

The root cause is CWE-177, improper handling of URL encoding. As the dev.to analysis reconstructs it, the authentication layer protects the j_security_check login endpoint using a filter that performs a literal string match on the request URI. An attacker percent-encodes a single character in that path — for example sending %6a, the hex encoding of the letter "j" — so the raw request no longer matches the filter's rule and is treated as needing no authentication. The backend, however, decodes the URI before routing it, resolves the request to the real protected endpoint, and serves it as privileged. Two components disagree about what the request is, and the forged request falls through the gap between them.

The CVSS vector is maximal: network-accessible, low attack complexity, no privileges required, no user interaction, and high impact on confidentiality, integrity and availability.

Exploited before disclosure

According to the analysis, Cisco's PSIRT learned of the flaw through a TAC support case, meaning a real customer incident surfaced the bug rather than internal research. CISA added the CVE to its Known Exploited Vulnerabilities catalog on the day of the advisory, September 30, giving federal agencies a patch deadline of October 3. The practical implication the write-up draws is that attackers had the technique in hand before defenders had the advisory.

Affected versions and fixed releases

Every configuration is affected; there is no setting that avoids the bug. The fixed releases listed are:

• 20.9 branch: 20.9.10.1
• 20.12 branch: 20.12.8.2
• 20.15 branch: 20.15.6.1 (cloud-hosted 20.15.605 was already fixed)
• 20.18 branch: 20.18.4.1
• 26.1 branch: 26.1.2.1
• 26.2 branch: 26.2.1

Releases older than 20.9 will not receive a fix and must be migrated to a supported branch.

Detection guidance

The advisory cited by the write-up points defenders at two log sources: serviceproxy-access.log and vmanage-server.log. The fingerprint to look for is requests to j_security_check that contain percent-encoded characters arriving from unknown or unexpected IP addresses. Separately, watch for anomalous activity by internal service accounts, particularly ones named viptela-reserved-*, which attackers may impersonate or abuse after gaining access. Because legitimate traffic to these endpoints is rare, encoded requests from unfamiliar sources deserve to be treated as hostile by default, and organizations that do not retain or centralize these logs should fix that first.

Why it matters

SD-WAN Manager is the control plane of the wide-area network, and a single instance can administer up to 6,000 devices. An attacker with administrator API access does not need to compromise individual branch routers — they can instruct the Manager to reconfigure them, harvest device credentials, alter routing policy to redirect traffic, or pivot from the management network into the enterprise. Because the exploit needs no credentials and only one request, the analysis warns that every internet-exposed Manager could have been fingerprinted within days of disclosure. The write-up also notes this fits a broader pattern of broken access control in enterprise infrastructure, where the code deciding who is allowed keeps failing in remotely exploitable ways.

What network teams should do

• Upgrade to the fixed release for your branch; no workarounds exist.
• If a Manager was internet-reachable and unpatched at any point in September 2026, audit the two log files for encoded j_security_check requests rather than assuming the network is clean.
• Rotate Manager admin credentials, API tokens, and the device credentials managed through the fabric, since admin API access can expose them.
• After patching, restrict management access to VPN or strict allow-lists so the next control-plane flaw finds no exposed target.