Revenge of the SD-WAN: Cisco Catalyst SD-WAN Manager Auth Bypass (CVE-2026-76504)

What it is

VulnCheck's technical writeup of CVE-2026-76504, a Cisco Catalyst SD-WAN Manager (vManage) authentication bypass disclosed as an exploited zero-day on September 30, 2026. The post documents the full reverse-engineering process (log analysis, Docker inspection, decompilation) behind the root cause already summarized, and adds exposure/exploitation context and detection artifacts not in the existing summary.

Preconditions / Affected

VulnCheck's Target Intelligence counts roughly 1,500 internet-exposed SD-WAN vManage devices as of the post date. As of October 1, 2026, VulnCheck states there is no legitimate public exploit (they reviewed and rejected one fake public PoC), and in-the-wild exploitation hasn't been attributed to a specific threat actor. This is the fifth zero-day Cisco SD-WAN vulnerability VulnCheck has analyzed this year, following CVE-2026-20127, CVE-2026-20182, and CVE-2026-20245.

How it works (reproduction detail)

Sending the crafted path with and without encoding produces two different error codes, which is what let VulnCheck locate the diverging code path:

• POST /j_security_check with bad creds → "Failed to login user" / "Invalid username or password" (normal password check ran).
• POST /%6a_security_check with bad creds → LOGIN000 / "userInfo is null" (password check was skipped entirely).

Tracing the stack showed WildFly (Undertow) serving j_security_check with no <servlet> mapping — auth logic lives entirely in Cisco's AppServerLoginModule, loaded from vmanage-server-1.0.0-SNAPSHOT.jar. Decompiling confirmed the vulnerable gate is request.getRequestURI().contains("j_security_check"), which fails against the encoded path and drops execution into the fallback "continue trusted session" branch that only checks isInternalUser() — a substring match against the four viptela-reserved-* names.

What to do

No patch, workaround, or vendor guidance is given in this text (Cisco's advisory is referenced but not reproduced). The only actionable detection pointers stated: watch serviceproxy-access.log and vmanage-server.log, and look for the viptela-reserved- string in matched usernames as an IoC anchor. VulnCheck notes a weaponized exploit, YARA rule, PCAP, ASM queries, and Snort/Suricata rules exist but are gated behind their paid Initial Access Intelligence product — not included on the page.

Caveats

• No official patch/fix version is stated in this text.
• The "fake public exploit" VulnCheck rejected is mentioned but not detailed (no indicators given to distinguish it).
• Detection artifacts (YARA/Snort/Suricata/PCAP) are described as existing but are not published in the post itself.