Cisco Catalyst SD-WAN Manager Authentication Bypass: What to Patch and What to Check

Cisco has patched an authentication bypass in Catalyst SD-WAN Manager — CVE-2026-76504, CVSS 9.8 — that lets a remote, unauthenticated attacker reach the management system as the administrator. Cisco's PSIRT became aware of active exploitation in September 2026, before a fix shipped.

Two details make this urgent rather than routine. There is no workaround — Cisco's advisory says so plainly, and the only remediation is a fixed release. And it affects Catalyst SD-WAN Manager regardless of how it is configured, so there is no deployment pattern that sits this one out.

If you run Catalyst SD-WAN Manager, this is a tonight job.

What the flaw is

The manager mishandles URI encoding in HTTP requests. An authentication rule intended to restrict access to a specific API endpoint can be bypassed by encoding part of the path, so a crafted request reaches the API without authenticating and comes back with admin access.

Observed exploitation encodes the login servlet: a request to POST /%6a_security_check instead of the literal j_security_check. %6a is simply the hex encoding of the letter j. The authentication filter compares the raw path against a literal string, the application layer decodes it later, and the two disagree about what is being requested.

That class of bug — one component making a security decision on a string another component will interpret differently — is worth recognising, because it recurs. It is the same shape as the NULL-byte path handling in the FortiMail zero-day patched a fortnight ago.

What to patch

Upgrade to one of these releases or later:

CISA gave federal agencies three days. That is a reasonable yardstick for anybody.

What to check, because patching is not the whole job

Exploitation began before the patch existed. If your manager was reachable during September, assume it was found and look for evidence either way.

Hunt the logs. Cisco's detection guidance is to look for POST requests to any URL-encoded variant of /j_security_check. Do not grep for %6a alone — any character in the string can be encoded, in upper or lower case hex, so %6A_security_check, j%5Fsecurity_check and similar are all candidates. A sensible pattern is any POST whose path contains a percent sign and ends in security_check.

Then look for what an admin would have done next:

• new or modified user accounts, especially administrative ones
• new API tokens or keys
• changes to device templates or policies — this is the one that matters most, because a template change pushes configuration to every edge device attached to it
• unexpected configuration pushes, and who authorised them
• new or altered scheduled tasks
• outbound connections from the manager to addresses you do not recognise

If you find anything, treat it as a compromise of the control plane. The manager configures your WAN. An attacker with admin on it does not need to attack your branches individually; it can push policy to them. Rotate credentials and certificates it holds, review every device template against a known-good copy, and get the configuration restored from a trusted backup rather than cleaned in place.

Suggestions beyond this CVE

The specific bug will be patched and forgotten. The condition that made it serious — a management plane an unauthenticated stranger could reach — is the part worth fixing permanently.

Take the management interface off the internet. Catalyst SD-WAN Manager does not need to accept connections from arbitrary addresses. Restrict it to a management network, reachable through a VPN or a zero-trust broker. This single change downgrades a CVSS 9.8 pre-auth bypass from an emergency to a scheduled patch, because the attacker cannot reach the vulnerable endpoint.

Put MFA in front of administrative access, at the broker if the product's own authentication does not support it well.

Separate the management plane from user traffic. The same argument as network segmentation generally: a management network that only administrators reach is a much smaller target than one any user VLAN can route to.

Subscribe to the vendor's PSIRT feed and actually triage it. The gap between Cisco's advisory and an attacker finding your instance is now measured in hours. Our patch management practices piece covers how to run that triage without patching everything on a Friday.

Know what your management planes are. SD-WAN controller, firewall manager, hypervisor console, backup server, wireless controller, PBX, building controls. Each one administers something, each is a high-value target, and in most environments at least one of them is reachable from somewhere it should not be. That inventory is a short exercise with a long payoff.

The wider pattern this fits

This is the third pre-authentication flaw in a security or network management appliance in a fortnight — alongside FortiMail and Ivanti Connect Secure. The devices sold to protect the perimeter are now a significant part of the perimeter's attack surface, because they are internet-facing by design, they run complex software, and they are trusted by everything behind them.

We have written that case up separately in three edge appliance zero-days in two weeks, including what to do when patching may be too late. The short version: patch on the vendor's timeline, assume exposure during the window before the patch, and reduce what is reachable so the next one is less of an event.

Sources

• Cisco Patches Exploited Catalyst SD-WAN Zero-Day Vulnerability — SecurityWeek
• Cisco warns of new SD-WAN authentication bypass zero-day exploited in attacks — BleepingComputer
• CVE-2026-76504: Catalyst SD-WAN Manager — ToolsLib
• Active Exploitation of Vulnerability in Cisco Catalyst SD-WAN Manager — Cyber Security Agency of Singapore