Table of contents
16
Read this in 30 seconds: CVE-2026-76504 is a CVSS 9.8 unauthenticated admin-access bug in Cisco Catalyst SD-WAN Manager, and Cisco confirms it’s already being exploited. The entire bypass is one percent-encoded character.
- The exploit is a single swapped character. Request
/j_security_checknormally and an access rule stops you. Request/%6a_security_check, the exact same path with “j” percent-encoded, and the same rule waves it through.- This isn’t a new bug class for this product. Cisco’s own disclosure record shows this is the fifth SD-WAN zero-day exploited in the wild in 2026 alone, following two auth-bypass and two file-write/root bugs already patched this year.
- There’s no workaround, only isolation. Cisco names no configuration fix, no way to disable the exposure, only restricting who can reach the management interface until you patch.
- CISA didn’t just set a deadline, it flagged this for forensic triage. Active exploitation plus a 3-day remediation window means: investigate for prior compromise before you assume patching alone made you safe.
- Cisco published a tell that’s hard to fake. The accounts this bug’s exploitation tends to touch carry a
viptela-reserved-prefix, internal service-account naming left over from before Cisco acquired Viptela’s SD-WAN technology, and it’s specific enough to search your logs for directly.
Access control that only checks what a request literally says, not what it actually means once decoded, is how “j” becomes a master key.
CVE-2026-76504 hit Cisco Catalyst SD-WAN Manager on September 30, 2026, rated the maximum practical severity, CVSS 9.8. Cisco says it’s already being exploited, and CISA’s response treats it as a possible-breach scenario, not a routine patch.
Here’s the mechanism, what’s confirmed versus inferred about why it works, and what to check on your own deployment.
Catalyst SD-WAN Manager, the product Cisco still calls vManage internally, is the single control plane for an organization’s entire software-defined WAN: it configures every branch router, pushes policy, and holds the relationships those routers trust. It’s the same product family behind four other zero-days already patched earlier in 2026, which is its own warning sign, covered below.
An auth bypass on a normal web app gets you into one application, but CVE-2026-76504 doesn’t stop there. An auth bypass on an SD-WAN controller gets you into the system that every router in the network already trusts by design, the same control-plane-to-edge-device relationship that made the Arista VeloCloud bug dangerous in September, except here the bypass needs nothing more exotic than a single changed character in a URL.
Here’s NVD’s description:
“A vulnerability in the API session-based authentication management of Cisco Catalyst SD-WAN Manager could allow an unauthenticated, remote attacker to access an affected system with privileges of the admin user. This vulnerability is due to improper handling of URI encoding in an HTTP request, which allows the request to bypass an authentication rule that is intended to restrict access to a specific API endpoint.”
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, scored by Cisco’s own PSIRT.The CVE-2026-76504 exploit itself is public and specific: send a request to /%6a_security_check instead of /j_security_check. %6a is just the percent-encoded form of the letter “j”, so the two paths are identical once decoded, and that’s exactly the point.
j_security_check isn’t a Cisco-specific name. It’s the standard Java EE servlet endpoint that handles form-based login processing, defined by the platform spec itself, which is why it shows up in enterprise Java products generally, not just this one. Cisco’s advisory and the request logs it points to (/var/log/nms/containers/service-proxy/serviceproxy-access.log) make clear there’s a service-proxy layer sitting in front of the backend, and that layer is what enforces the access rule meant to restrict direct calls to that endpoint.
Here’s the part to be precise about: neither Cisco’s advisory nor the independent write-ups we could find explain the exact reason the bypass works, only that it does. The most likely explanation, based on what’s confirmed, is a mismatch between two layers: the service-proxy’s access rule checks the request path as written, before decoding, while the backend Java container decodes the path and still routes %6a_security_check to the real j_security_check handler. A rule matching on the literal string “j_security_check” simply never sees a match against “%6a_security_check”, so it lets the request through unblocked, and the backend processes it anyway once decoded. That mechanism is inference from the available evidence, not something Cisco has stated directly, and we’re labeling it that way rather than presenting it as confirmed.
What is confirmed is what happens next: authentication log entries tied to exploitation show sessions authenticating as accounts with a viptela-reserved- prefix, internal service-account naming inherited from Viptela, the company Cisco acquired to build its SD-WAN product line. Cisco doesn’t spell out exactly how reaching the login-processing endpoint directly, bypassed access rule and all, results in a session for one of these reserved accounts specifically, but the IOC is specific enough to search for regardless of the exact internal mechanics.
CVE-2026-76504 isn’t an isolated incident for this product line. Four other Cisco Catalyst SD-WAN zero-days were disclosed and exploited earlier the same year:
Five zero-days in one product family in one year, each independently exploited, is the kind of pattern worth factoring into how urgently you treat the next one, this one included. If your organization runs Catalyst SD-WAN at all, patching CVE-2026-76504 is not the end of the list, it’s the most recent entry on it.
You’re exposed to CVE-2026-76504 if both of these are true:
Cisco’s own advisory names two specific places to look, and they’re worth using directly:
# Encoded-path exploitation attempts against j_security_check
grep -i '%6a_security_check\|%4A_security_check' /var/log/nms/containers/service-proxy/serviceproxy-access.log
# Authentication activity tied to reserved service accounts
grep 'viptela-reserved-' /var/log/nms/vmanage-server.logWhat to check for CVE-2026-76504 specifically:
/var/log/nms/containers/service-proxy/serviceproxy-access.log showing an encoded character in the j_security_check path, such as POST /%6a_security_check HTTP/1.1, from an IP address you don’t recognize as legitimate administrative access./var/log/nms/vmanage-server.log tied to a username beginning with viptela-reserved-. These are internal service accounts; a login attempt against one from outside your expected automation is a strong signal, not a false positive to dismiss.
The part of this CVE-2026-76504 bug worth testing for isn’t the specific %6a trick, it’s the broader question it raises: does every layer that’s supposed to enforce a security rule actually agree on what the request means? A proxy that blocks based on the literal bytes in a URL, sitting in front of a backend that normalizes and decodes before acting, is a mismatch that shows up again and again across completely unrelated products, because it’s a property of how the layers were built, not a one-off coding mistake.
We’d test an access-control boundary like this by deliberately varying encoding, case, and path structure against every rule that’s supposed to restrict access, not just confirming the rule blocks the obvious, unencoded case. That’s exactly the kind of gap between “the rule exists” and “the rule actually holds” a thorough external penetration test is built to find before an attacker does.
Our ultimate penetration testing checklist covers how that kind of engagement gets scoped end to end, and our cloud infrastructure penetration testing methodology covers the control-plane side of the same problem for teams running orchestration and management tools like SD-WAN Manager alongside their broader infrastructure.
CVE-2026-76504 is a CVSS 9.8 unauthenticated authentication-bypass vulnerability in Cisco Catalyst SD-WAN Manager. An attacker sends a request to the standard Java login-processing endpoint with one character percent-encoded (/%6a_security_check instead of /j_security_check), which bypasses an access rule meant to restrict that endpoint and results in admin-level API access with no credentials.
Yes. Cisco’s advisory confirms active exploitation, and CISA added it to the Known Exploited Vulnerabilities catalog on the same day it was published, September 30, 2026, with a 3-day remediation deadline.
Versions 20.9 through 20.9.9.x, 20.12 through 20.12.8.1, 20.15 through 20.15.6.0, 20.18 through 20.18.4.0, 26.1 through 26.1.2.0, 26.2 through 26.2.0.x, and all versions before 20.9. Cisco states the vulnerability affects the product regardless of configuration.
No. It’s the fifth. CVE-2026-20127 (February), CVE-2026-20182 (May), and CVE-2026-20245 and CVE-2026-20262 (both June) were all exploited SD-WAN zero-days patched earlier in 2026, covering authentication bypass, CLI access, and file-write-to-root paths.
No. Cisco names no configuration-based workaround. The only mitigation short of patching is restricting network access to the SD-WAN Manager management interface to trusted hosts behind a firewall.
Upgrade to 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1, 26.2.1, or 20.15.605 for cloud-managed deployments, whichever matches your current release train. Before or immediately after patching, check your service-proxy and vManage server logs for the indicators Cisco published.
CVE-2026-76504 doesn’t need a misconfiguration, a missing patch on some unrelated dependency, or a clever chain of bugs. It needs one character in a URL encoded differently than the rule in front of it expects, and the rule stops meaning anything. Cisco confirms it’s already been used this way, and it’s the fifth time this exact product line has had a zero-day exploited in 2026.
Patch to the fixed build for your train, lock down who can reach the management interface either way since there’s no workaround, and run Cisco’s own log searches before you assume the patch closed the door on time.
Categories
Related articles
