CRITICAL: Cisco Catalyst SD-WAN Manager Auth Bypass Exploited in the Wild

If you manage Cisco Catalyst SD-WAN and you were hoping 2026 would finally give you a quiet quarter, I have bad news. Cisco has confirmed that attackers are actively exploiting CVE-2026-76504, a critical authentication bypass in Catalyst SD-WAN Manager that hands an unauthenticated remote attacker admin-level access to the API. CISA added it to the Known Exploited Vulnerabilities catalog right after Cisco published its advisory on September 30, and gave federal civilian agencies until October 3 to fix it. That deadline is today. If you haven't patched yet, this is your sign.

The flaw carries a CVSS 3.1 score of 9.8, and it earns every decimal. No credentials are needed and no user has to click anything. The target is the product that sits at the center of your wide area network and pushes configuration to every edge router you own. Compromise the manager and you aren't looking at one box. You're looking at the whole fabric.

What Went Wrong

The root cause is one of those bugs that makes seasoned engineers sigh loudly. Cisco describes it as improper handling of URL encoding in the API-based session authentication logic, which maps to CWE-177. SD-WAN Manager, which many of us still call vManage out of habit, has a rule meant to restrict access to a specific authentication endpoint. That rule checks the request path as a literal string. The web stack behind it, however, happily decodes percent-encoded characters before routing the request. So an attacker who sends a POST to something like /%6a_security_check instead of /j_security_check slides right past the restriction, because %6a is just the hex encoding of the letter j. The filter sees a path it doesn't recognize, the backend sees the endpoint it knows, and the attacker walks away with an authenticated admin session.

Rapid7 points out that any single character in that path can be encoded, so %6a is merely one example. That matters for detection, which I'll come back to, because anyone writing a regex for one specific encoded string is going to miss the next variant.

Path normalization mismatches between a security check and the component behind it are not new. We have watched this exact class of bug bite load balancers, reverse proxies, and Java application servers for the better part of two decades. It's a little disheartening to see it show up again in a product whose entire job is enforcing trust boundaries.

Affected Versions and Fixes

Every configuration of on-premises Catalyst SD-WAN Manager is vulnerable, and there is no workaround. Cisco has shipped fixed releases across all supported trains. Release 20.9 is fixed in 20.9.10.1, release 20.12 in 20.12.8.2, release 20.15 in 20.15.6.1, and release 20.18 in 20.18.4.1 and later. On the newer numbering, 26.2.1 fixes the 26.2 train and 26.1.2.1 covers the 26.1 train. If you're still running something older than 20.9, there is no patch coming for you, and Cisco's guidance is to migrate to a fixed release. Customers on Cisco's cloud-delivered SD-WAN were moved to 20.15.605, which contains the fix, so no action is required on their end.

Cisco's interim advice is to restrict access to the manager from untrusted networks and limit connections to known hosts with an upstream filtering device. That is good hygiene and you should do it anyway. But the vendor is explicit that it does not replace the upgrade, and I'd agree. An ACL is a speed bump. The patch actually removes the road.

Exploitation in the Wild

Cisco's PSIRT says it became aware of exploitation during September, before the advisory went public. That means this was used as a zero-day. The company has declined to share how many customers were hit, when the first compromise happened, or who is behind it. That silence is frustrating but not unusual for Cisco PSIRT on active campaigns.

What we do know is that the target set is attractive. Jake Knott of watchTowr noted that Cisco SD-WAN "feels like an ever-present staple" of the KEV list, with eight 2026 CVEs from the platform landing there this year alone. That tells you threat actors have built real tooling and real muscle memory around this product line. CVE-2026-76504 is also the third authentication bypass in Catalyst SD-WAN control components this year. It follows CVE-2026-20127 and CVE-2026-20182, both of which went after the vdaemon service. This one takes a different route entirely, through the HTTP API, which suggests attackers and researchers are systematically working through every entry point the platform exposes.

The appeal is obvious once you think like the attacker. SD-WAN Manager is a single pane of glass for the enterprise network. Admin access lets you read and change routing policy, push configuration templates to edge devices, pull device credentials and certificates, and quietly redirect traffic. For an espionage crew that is a dream foothold. For a ransomware affiliate it is a map of everything worth encrypting and a way to make sure nobody can route around the damage. In intrusions involving network management planes, the attacker rarely stops at the first box. They use it as a launchpad, and they tend to leave persistence behind in places most teams never think to check.

Hunting for Compromise

Patching closes the door, but it doesn't tell you whether someone already walked through it. Given that exploitation predates disclosure, every exposed instance deserves a look. Before you upgrade, preserve your logs and run the admin-tech command so you have a forensic snapshot. Upgrades have a nasty habit of rotating away the evidence you need.

There are two log files to focus on. The first is /var/log/nms/containers/service-proxy/serviceproxy-access.log, where you want POST requests to the security check endpoint containing percent-encoded characters anywhere in the path. Don't hunt only for %6a. Look for any percent sign in a request to that endpoint, because a legitimate browser login has no reason to encode those letters. The second is /var/log/nms/vmanage-server.log, where Cisco advises searching for j_security_check activity tied to usernames beginning with viptela-reserved-. Those reserved system account names should not show up in interactive logins from random addresses. If you see them associated with source IPs outside your management networks, treat the box as compromised.

Beyond the logs, review the admin user list for accounts you did not create, check recent template and policy changes against your change management records, and look at configuration pushes to edge devices during September. If anything looks off, open a case with Cisco TAC and assume credentials stored on or managed by the platform need rotation. For teams with a SIEM, a simple detection that alerts on encoded characters in authentication paths to SD-WAN Manager is cheap to build and will keep paying for itself, given how often this product family shows up on the KEV list.

It's also worth running an external scan of your own address space today. Plenty of organizations have SD-WAN Manager reachable from the internet because a contractor needed access three years ago and nobody closed it. Rapid7 put it bluntly when it said that systems with ports exposed to the internet are at risk. If yours shows up on Shodan, the attackers already know about it.

The Bigger Picture

There is a broader lesson buried in this one. Network management planes have become one of the most consistently targeted categories of enterprise software, right alongside VPN concentrators and email gateways. They are high value, they often get patched slowly because nobody wants to touch the thing that runs the WAN, and they frequently sit outside the reach of the endpoint detection tools that would flag suspicious behavior on a normal server. That combination keeps attackers coming back.

The fix is part technical and part organizational. Management interfaces belong on isolated management networks, reachable only through jump hosts with strong authentication. Patching for these platforms needs a defined emergency path that doesn't require a two-week change advisory board cycle when CISA hands you a 72-hour deadline. And logs from these devices need to land somewhere a human or a detection rule will actually read them.

For now, the priority order is simple. Find every Catalyst SD-WAN Manager instance you own, pull the logs and admin-tech output, hunt for the indicators above, then upgrade to the fixed release for your train. If you are running anything older than 20.9, start the migration conversation today. This is a drop everything and patch it now situation, and the people exploiting it aren't waiting for your next maintenance window.

The MSP Angle

Any client running Cisco SD-WAN needs an emergency patch and compromise assessment this week, and that's a clean, billable project with a clear scope. It's also the right moment to pitch an external attack surface review and log forwarding from network management planes into a managed SIEM, because the next SD-WAN KEV entry is probably already on its way.