Cisco published an advisory on September 30 for CVE-2026-76504, a critical Cisco Catalyst SD-WAN Manager authentication bypass scoring 9.8. Cisco’s Product Security Incident Response Team confirmed attackers were already exploiting it in September. CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave federal agencies until October 3 to remediate.
The Rule Matched the Text It Saw. The Server Matched the Path It Decoded.
Catalyst SD-WAN Manager, formerly vManage, guards one API endpoint with a rule that matches the request path against the literal string j_security_check. A request does not have to arrive as plain text. Percent-encode a single character so the path reads /%6a_security_check, and the rule stops matching. The application resolves the same handler anyway. One layer authorized the bytes it was handed, another routed on what those bytes decoded to. An unauthenticated attacker lands on the API holding admin privileges. Cisco is explicit that %6a is only an example, so blocking that literal string at the edge buys nothing.
Patching Closes the Door. It Does Not Evict Anyone.
There is no workaround. Cisco’s only mitigation is placement. Keep the manager off the internet, behind a filtering device, and allow traffic from trusted hosts. Teams exposed it because reaching it remotely was easier than building the access path.
The exploit grants admin API access, enough to add accounts, rewrite configuration, and push policy to every device the console reaches. Cisco’s guidance is to collect its indicators of compromise and open a support case. CISA asks for more than a patch. Under its own directive, agencies must also check whether the system was compromised before the fix went on.
Cisco has not said how many systems were hit or who is behind the attacks. Treat an internet-exposed manager as probed, not breached.
Cisco’s SD-WAN line has produced nine entries on the Known Exploited Vulnerabilities catalog this year alone. Cisco shipped fixes in February and again in May. Neither covers this one, so patching on schedule left operators exposed again.
Three questions worth answering today. Can anything outside your trusted networks reach the manager? Do your logs show j_security_check requests from an address you do not recognize? And if that API answered to someone else tonight, what could they change before morning?
Related reading. Arista patched VeloCloud in July and shipped a build that was still vulnerable.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.
