Cisco Catalyst SD-WAN Manager API Authentication Bypass

Cisco has published an advisory for CVE-2026-76504, an authentication bypass in API session management of Cisco Catalyst SD-WAN Manager. The flaw is rated critical. Per the advisory, an unauthenticated, remote attacker can "access an affected system with privileges of the admin user" by sending a crafted HTTP request to a specific API endpoint. For a product that sits at the operational apex of a wide-area network, this disclosure warrants reading now, not next sprint.

This post covers the mechanism, the precondition for exploitation, how to assess exposure, and what to do before this appears on the exploited-in-the-wild lists.

What the flaw actually is

Catalyst SD-WAN Manager (the controller formerly branded vManage) exposes a REST and NETCONF-adjacent API that administrators and automation use to push device templates, pull telemetry, and orchestrate overlay changes. Access is gated by session-based authentication: an authentication rule restricts specific endpoints to logged-in callers.

Per the advisory, the bug is in how that rule handles URI encoding. A single HTTP request whose URI the authentication layer normalises differently than the downstream dispatcher bypasses the rule and lands on a restricted endpoint with admin identity. In the vendor's own description: "improper handling of URI encoding in an HTTP request" allows the request to "bypass an authentication rule that is intended to restrict access to a specific API endpoint."

The class is well understood. When two components in the same request path disagree on what a URI means (one decodes %2e%2e, //, or a mixed-case scheme-relative prefix while the other does not; one strips a trailing slash while the other treats it as a different route; one treats ; matrix parameters as part of the path while the other does not), a filter matching "the path begins with /restricted" can be sidestepped by any transformation that still routes to /restricted downstream. Cisco has not published the exact token. The vulnerable surface is the gap between the auth filter's view of the URI and the handler's view of the same URI.

Two things to internalise:

The precondition an attacker needs

In order of what gates exploitation:

  1. Network reachability to the SD-WAN Manager management interface or API over HTTPS. On-prem deployments typically restrict this to a management VLAN; cloud-hosted deployments restrict it with a tenant allowlist. Where either control has slipped (a bastion with a stale rule, a jump host left dual-homed, a load balancer that exposes the API alongside the dashboard), the precondition is met.
  2. An affected software train. Treat every version as suspect until matched against the vendor's fixed-release table. Operators who patch quarterly almost certainly run a vulnerable image today.
  3. The crafted URI. This is the attacker's problem, not the defender's. Public PoCs for URI-encoding bypasses tend to arrive within days of the first serious write-up.

Nothing on this list requires phishing, lateral movement, or an insider. If the API is reachable from an attacker's vantage point and the box is unpatched, the attacker is one request away from admin.

How to determine exposure

Patch state and reachability are the two questions. Answer both; do not conflate them.

Reachability. Enumerate every path to the SD-WAN Manager API, not just the one the runbook documents. From an untrusted vantage point (an external scanner for internet exposure; a workstation VLAN for east-west exposure), probe the management IP and any FQDN that resolves to it:

# Does the API answer at all from here?
curl -skI https://sdwan-manager.example.com/dataservice/client/server \
  | head -n 1

# What TLS cert is bound? Catch stale load-balancer VIPs
# that still terminate to the manager.
echo | openssl s_client -connect sdwan-manager.example.com:443 \
  -servername sdwan-manager.example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Any 2xx, 3xx, or 401 to an unauthenticated caller from a network that should not reach the API is a finding on its own, independent of this CVE.

Patch state. Pull the running image version through your existing inventory source of truth. If that source is the manager itself, verify it against the controller's own About output and against the orchestrator record: an attacker who already has admin can tamper with one source but not the other. Map the version against the fixed-release table in the Cisco PSIRT advisory for CVE-2026-76504 and treat anything not explicitly listed as fixed as vulnerable.

Post-compromise signal. Pre-auth bypasses leave typical API-abuse residue. Review controller access logs for: unauthenticated requests to restricted endpoints that returned 200 rather than 401 or 403; admin-privileged actions (template pushes, device onboarding, user creation, certificate operations) attributed to a session whose login event you cannot locate; and sessions whose source IP does not match a known administrator jump host. Preserve logs offline before patching, since upgrade workflows on some trains rotate state.

What to do before this reaches the KEV list

Recent CISA KEV additions (CVE-2026-87902 in WordPress Core, CVE-2026-67279 in MikroTik RouterOS, CVE-2026-65660 in Microsoft SharePoint, CVE-2026-71362 in Adobe Commerce and Magento, and CVE-2026-5430 in WSO2 products) confirm the pattern: critical, network-reachable, pre-auth or near-pre-auth flaws on identity-adjacent or management-plane components reach KEV within days to weeks of first public exploitation. BOD 26-04, which took effect 2026-06-10, carries the KEV criteria forward and makes remediation a standing obligation for federal civilian agencies. Private operators should apply the same urgency whether or not the directive binds them.

Concretely, before CVE-2026-76504 goes KEV:

Reachability plus a patched image closes the window. Hunting plus rotation closes the one you may already have missed.

Verifiable security.