Deep Dive: CVE-2026-76504, Authentication Bypass in Cisco Catalyst SD-WAN Manager

Thu, 08 Oct 2026 00:00:00 +0000

Introduction

On 30 September 2026, Cisco published advisory cisco-sa-sdwan-webauth-xr8beuuU for CVE-2026-76504, a critical authentication bypass in Cisco Catalyst SD-WAN Manager (formerly vManage). Cisco found the flaw while its Technical Assistance Center (TAC) was working on a customer support case. By then, attackers were already exploiting it. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog the same day and gave US federal agencies three days to fix it.

The bug sounds almost trivial: replace the letter j with its URL-encoded form %6a in the login path, and an authentication rule stops applying. The result is not trivial at all. The attacker gets access to the management API as the built-in admin user, which controls the configuration and policies of every router the Manager administers.

For SOC teams, this is the latest of several exploited SD-WAN Manager flaws in 2026, and it needs both quick patching and a real investigation. This article explains how the vulnerability works, what is publicly known about its exploitation, and how to hunt for it and respond.

This analysis reflects public information available on 8 October 2026.

Risk Snapshot

Signal	Assessment
🔴 CVSS v3.1	9.8 / CRITICAL (`AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`)
🧬 Weakness	CWE-177, Improper Handling of URL Encoding
🎯 Product	Cisco Catalyst SD-WAN Manager, any configuration
🔓 Auth Required	None
👑 Resulting Privilege	Built-in `admin` user (netadmin role) on the management API
⚠️ Exploitation	In the Wild ✓ (identified in September 2026)
📌 KEV Listed	30 September 2026, federal due date 3 October 2026
🛠️ Workaround	None, upgrade required
☁️ Cisco-managed cloud	Already fixed (20.15.605), no customer action

Section 1: Technical Overview of CVE-2026-76504

What is Catalyst SD-WAN Manager?

Catalyst SD-WAN Manager is the centralized management plane of Cisco’s SD-WAN solution, inherited from the Viptela acquisition. Administrators use its web interface and REST API to build device templates, define routing and security policies, and push them to the WAN Edge routers and control components across every site.

That central role is what makes it such a valuable target. An attacker with admin access to the Manager does not compromise one device; they gain control over routing policies, segmentation rules, device configurations and administrative accounts across the whole fabric.

The vulnerability

Cisco describes the root cause as follows:

“This vulnerability is due to improper handling of URI encoding in an HTTP request, which allows the request to bypass an authentication rule.”
Cisco Security Advisory cisco-sa-sdwan-webauth-xr8beuuU

The flaw sits in the session-based authentication of the management API. An unauthenticated, remote attacker sends a crafted HTTP request and gains access to the API with the privileges of the admin user. By default, that account holds the netadmin role, which allows every operation. Cisco states that the Manager is affected regardless of its configuration.

Public analyses from Rapid7 and Horizon3.ai identify the target: j_security_check, the form-login endpoint. The indicator shared publicly is a request in which the first letter is URL-encoded:

POST /%6a_security_check HTTP/1.1

0x6a is the ASCII code of j. Once decoded, the path is the ordinary login endpoint. Before decoding, it is a string that the authentication rule apparently does not recognise.

Why does one encoded letter matter?

This is a classic case of CWE-177: two parts of the same application read one path in two different ways. A security check is evaluated against the raw form of the URL. Another component then decodes or normalises the path before routing it. If the two disagree, a request can be “unknown” to the check and still reach the protected function.

Figure 1. Conceptual illustration of the bug class. Cisco has not published implementation details; the exact internal components involved are not public.

One point is useful for detection. j_security_check is the normal login path, so legitimate logins hit it all the time. However, according to RFC 3986, letters, digits and - . _ ~ are unreserved characters that clients should not percent-encode. A browser or a regular API client has no reason to send %6a instead of j. An encoded letter in a login path is therefore a much stronger signal than the login path alone.

Affected and fixed versions

Release train	First fixed release
Earlier than 20.9	Migrate to a fixed release
20.9	20.9.10.1
20.12	20.12.8.2
20.15	20.15.6.1
20.18	20.18.4.1
26.1	26.1.2.1
26.2	26.2.1
Cisco-managed cloud	20.15.605 (already deployed by Cisco)

Always confirm the target release against the latest revision of the Cisco advisory before scheduling the change. Fixed-release tables are sometimes updated after publication.

Section 2: Exploitation & Threat Landscape

What is known

Exploitation was observed before disclosure. Cisco identified in-the-wild exploitation in September 2026 while handling a TAC case. The investigation window therefore starts before 30 September, not on that date.
CISA set a three-day deadline. The KEV entry was added on 30 September with a remediation due date of 3 October 2026 for US federal civilian agencies. That is far shorter than the usual two weeks given for new KEV entries.
No verified public exploit, but the request is trivial. As of 1 October, SOCRadar reported no independently verified working exploit. Still, the indicator itself (/%6a_security_check) is public, and rebuilding such a request takes minutes. Opportunistic scanning should be expected.
No public attribution. Cisco has not disclosed who is behind the activity, how many organisations are affected or what the attackers were after.

A product under sustained pressure

CVE-2026-76504 is not an isolated case. SD-WAN Manager has been a recurring target throughout 2026:

CVE	Disclosed	Type
CVE-2026-20127	February 2026	Authentication bypass (CVSS 10.0)
CVE-2026-20182	May 2026	Authentication bypass (CVSS 10.0)
CVE-2026-20245 / CVE-2026-20262	June 2026	Privilege escalation
CVE-2026-76504	September 2026	Authentication bypass (CVSS 9.8)

According to The Hacker News, CISA’s KEV catalog listed eight Cisco SD-WAN vulnerabilities for 2026 as of 30 September.

Earlier campaigns against this product were linked to UAT-8616, a sophisticated actor active since at least 2023. Tenable summarises its post-compromise tradecraft: rogue account creation, SSH key injection, NETCONF manipulation, software downgrades to reach an older privilege escalation flaw (CVE-2022-20775) before restoring the original version, and log clearing.

⚠ Attribution caution
There is no public link between UAT-8616 and CVE-2026-76504. We use this tradecraft below only as a set of hunting hypotheses, because it shows what an attacker with admin access to a Manager has done before.

Section 3: SOC Perspective, Detection & Hunting

Where to look

Cisco’s advisory points to two log files on the Manager:

Log file	What to review
`/var/log/nms/containers/service-proxy/serviceproxy-access.log`	`j_security_check` requests from unknown or unauthorised IP addresses, especially encoded variants such as `/%6a_security_check`
`/var/log/nms/vmanage-server.log`	Activity involving usernames that begin with `viptela-reserved-`

Two warnings from experience with path-encoding bugs:

Do not search only for %6a. Any other letter of the path can be encoded (/j_%73ecurity_check, %4a, double encoding, etc.). Search for the decoded path and compare it to the raw one.
Plain j_security_check requests are normal. Cisco itself notes that these entries can appear during normal operations. Compare sources and timing against your baseline of administrator IPs.

Quick check on exported logs

Start by copying the logs off the box (see Section 4), then run a first pass:

# Login requests containing percent-encoding (rotated and compressed logs included)
zgrep -i 'security_check' serviceproxy-access.log* | grep -E '%[0-9A-Fa-f]{2}'

# Activity involving reserved internal accounts
zgrep 'viptela-reserved-' vmanage-server.log*

The first command misses cases where the encoding is inside security_check itself. This short script decodes every request path and flags those that only become a login path after decoding:

import gzip, re, sys
from urllib.parse import unquote

# Adapt this pattern to your access-log format
REQ = re.compile(r'"(GET|POST|PUT|PATCH|DELETE|HEAD|OPTIONS) (\S+)')

for path in sys.argv[1:]:
 opener = gzip.open if path.endswith(".gz") else open
 with opener(path, "rt", errors="ignore") as log:
 for line in log:
 m = REQ.search(line)
 if not m:
 continue
 raw = m.group(2)
 decoded = unquote(unquote(raw)).lower() # also catches double encoding
 if "security_check" in decoded and raw.lower() != decoded:
 print(f"{path}: {line.rstrip()}")

SIEM detection (Splunk example)

If the Manager logs are forwarded to your SIEM, the same logic becomes a detection rule. Field names depend on your onboarding:

index=<sdwan_index> source="*serviceproxy-access.log*"
| rex field=_raw "\"(?<method>[A-Z]+) (?<uri_path>\S+)"
| eval decoded=lower(urldecode(urldecode(uri_path)))
| where like(decoded, "%security_check%") AND lower(uri_path)!=decoded
| stats count min(_time) as first_seen max(_time) as last_seen values(method) as methods values(uri_path) as raw_paths by host
| convert ctime(first_seen) ctime(last_seen)

Because legitimate clients do not encode letters in this path, any match deserves triage. On the network side, SOCRadar reports Cisco Snort rule SID 67179 for this vulnerability. A reverse proxy or WAF in front of the Manager can also block percent-encoded unreserved characters in request paths.

After a hit: what did the attacker do?

Admin access to the API means the attacker could create access that survives the patch. Use the earlier SD-WAN tradecraft as hunting hypotheses:

New or modified local users, especially with the netadmin role
API sessions or administrative actions from IP addresses outside your management network
Template or policy changes, and pushes to edge devices, that do not match a change ticket
New SSH authorised keys, and NETCONF sessions (TCP 830) from unexpected sources
Software version changes, including a downgrade followed by a return to the original version
Gaps, truncation or deletion in the log files themselves

Section 4: Response & Mitigation

Figure 2. Suggested order of operations, based on Cisco’s advisory guidance. Collect evidence before the upgrade changes the system.

1 — Preserve the evidence first

Before any change, run request admin-tech on every Manager and copy the existing logs to external storage. An upgrade, a reboot or log rotation can destroy what you need to answer “were we compromised?”. Cisco also asks for the admin-tech file when you open a TAC case.

2 — Hunt from the earliest available date

Exploitation started before the advisory. Run the searches above over the full retention period, not only from 30 September. If retention does not cover September, record that gap explicitly in the incident file.

3 — Restrict access immediately

There is no workaround, but exposure can be reduced in minutes. Management interfaces (TCP 443, 22 and 830) should never be reachable from the internet. Allow only known, trusted hosts and place the SD-WAN control components behind a filtering firewall.

4 — Upgrade as an emergency change

Move to the first fixed release of your train (see the table in Section 1). Releases earlier than 20.9 must be migrated. This should not wait for the regular patch cycle.

5 — Verify and close

Review accounts, keys, templates and policies against a known baseline. Rotate the credentials of Manager administrative accounts. If you suspect compromise, open a TAC case with the CVE number in the title and involve your incident response team.

Action	Owner	Done when
Collect admin-tech and logs	Network team / SOC	Archive stored off-box, hash recorded
Hunt for encoded login paths and reserved users	SOC	Results reviewed over the full retention period
Restrict management access	Network / Firewall team	Access tested and refused from an untrusted network
Upgrade to a fixed release	Network team	Version in the Manager matches the fixed release
Review accounts, keys, templates and policies	SOC + Network team	Every difference vs. baseline explained or remediated

Conclusion

CVE-2026-76504 shows how small an authentication bypass can be: one percent-encoded letter in a login path. The impact is the opposite. An unauthenticated attacker gets admin control over the system that configures an organisation’s whole WAN.

For SOC teams, the key takeaways are:

Treat every internet-reachable SD-WAN Manager as potentially compromised until it has been hunted, not only patched.
Preserve before you patch. Run request admin-tech and export the logs before the upgrade.
Hunt for the decoded path, not just %6a. Attackers can encode any character.
Patching closes the door, not the access already gained. Check accounts, keys and configuration changes.
Take the management plane off the internet. With several exploited SD-WAN Manager flaws in 2026, exposure is the common factor.

As the situation evolves, check the Cisco advisory and the CISA KEV catalog for updated versions and indicators.

Pedro Ribeiro Magalhães on Senthorus Blog