Cisco published an advisory on 30 September 2026 for CVE-2026-76504, an authentication bypass in Catalyst SD-WAN Manager scored at 9.8. An unauthenticated attacker who can reach the interface gets API access with the privileges of the admin user. Cisco says its product security team became aware of exploitation during September. CISA added the identifier to its Known Exploited Vulnerabilities catalogue the same day.

There is no workaround. The flaw does not depend on how the product is configured.

The bug is a string comparison

Cisco classifies it as improper handling of URL encoding. In practice that means the authentication rule protecting the login endpoint matches on the literal path, and the server resolves the path after that check.

Encode one character of the endpoint name in hex — writing the letter j as %6a, which any web server decodes back to j — and the rule no longer recognises the request. The request still reaches the same handler. The check that was supposed to gate it simply does not fire.

That is the whole exploit. No memory corruption, no race, no credentials, no second stage.

Why this class keeps happening

A rule that lists paths is making a claim about what the server will do with a string, and a web stack normalises strings in more ways than a rule tends to enumerate: percent-encoding, double encoding, trailing dots, path separators, case. Each one is a different spelling of the same route.

The defence is not a longer list. It is to make the authorisation decision after the request has been resolved to a route, at the point where the application knows which handler is about to run. Where the check is placed matters more than how carefully it is written.

Root Notes covered a separate flaw in the same product line earlier this year. Two in one management product, in one year, is a pattern worth noting: management planes are the part of the network estate most likely to be exposed and least likely to be re-architected.

What the admin API is worth

The score is 9.8 because of what sits behind the login, not because of how clever the bypass is.

Catalyst SD-WAN Manager is the controller for an organisation's wide-area network. From its API an administrator creates device templates and pushes them, onboards and claims routers, manages the certificates those routers trust, and reads the configurations of everything already enrolled. An attacker holding that API holds the same levers.

Two of them matter more than the rest. Configuration push means the attacker can change what every managed edge device does — routing, tunnels, access rules — from one place and have it applied as an authorised change. And stored configurations are a credential archive: the keys, community strings and shared secrets the edge devices use to talk to the rest of the estate are in there to be read.

It also makes detection awkward in the ordinary case. The malicious request goes to the login path, so it lands in the same logs as every failed sign-in on a device that collects thousands of them, and everything the attacker does next is an authorised API call from an admin session. The anomaly is not the traffic; it is that the session exists at all.

Who needs to act, and by when

The affected branches, with their fixed builds, are:

  • 20.9 before 20.9.10.1
  • 20.12 before 20.12.8.2
  • 20.15 before 20.15.6.1
  • 20.18 before 20.18.4.1
  • 26.1 before 26.1.2.1
  • 26.2 before 26.2.1

For federal agencies, the catalogue entry brings BOD 26-04 with it, which sets the clock by exposure and automatability rather than by score. An internet-reachable management console with a one-request exploit is the worst combination that directive recognises, and it also asks for evidence collection before remediation on exposed assets.

For everyone else, the same two facts apply: it is reachable, and a single request does it.

What to do

  • Patch to the fixed build for your branch. There is no configuration that avoids this one.
  • Before patching an instance that was internet-reachable, collect evidence. Capture the access logs and look for requests to the login endpoint with any character percent-encoded.
  • Check for admin-level API activity that did not come from a known console session: user creation, template changes, device configuration pushes, certificate operations.
  • Take the management plane off the public internet. A controller that administers your network edge does not need to be reachable from it.
  • Rotate administrative credentials and API tokens on any instance you cannot rule out.

What is not established

  • Who is exploiting it. Cisco attributes the activity to nobody.
  • How many instances have been compromised, as opposed to scanned.
  • When exploitation began. Cisco says only that its team learned of it in September.
  • Whether any post-exploitation tooling has been recovered and published.