Cisco Catalyst SD-WAN Manager CVE-2026-76504: Admin API Auth Bypass Exploited

• 1September 2026 — Cisco's Product Security Incident Response Team (PSIRT) identifies active exploitation of the flaw while handling a Technical Assistance Center (TAC) support case.
• 2September 30, 2026 — Cisco publishes the security advisory and the NVD record goes live; the bug is rated CVSS 9.8 with exploitation already observed.
• 3October 1, 2026 — CISA adds CVE-2026-76504 to the Known Exploited Vulnerabilities catalog, binding federal agencies to a short remediation deadline under BOD 22-01.
• 4October 1–3, 2026 — Independent analyses from Rapid7 and Horizon3.ai detail the encoding trick against the j_security_check endpoint, confirming how trivially the auth rule is defeated.

Catalyst SD-WAN Manager uses a Java-style form-authentication flow whose login handler lives at the well-known path j_security_check. An authentication/authorisation rule is meant to govern access to that endpoint. The flaw (CWE-177, improper handling of encoding) is that the rule matches the literal request path, while the back-end servlet URL-decodes the path before dispatching. Feed the two a percent-encoded character and they resolve the request to different strings — so the rule fails to match, and the request sails through as if it were on an unprotected route, while the servlet still routes it to the real login handler.

Because the bypass targets the authentication step itself, there is no exploit chain, no memory corruption and no second stage. The crafted request is the exploit: once the rule is skipped, the login handler issues a valid session as the built-in admin account. From there the attacker speaks to the Manager's REST API as a fully privileged operator. Low attack complexity in the CVSS vector is literal here — it is a single, deterministic HTTP request.

The bypass is noisy in the right logs. Because the servlet still processes the decoded request, the Manager records the encoded path and, critically, maps the session to an internal service identity. Cisco's remediation guidance calls out log entries where an encoded j_security_check request is processed for a username beginning with viptela-reserved- — a reserved internal account prefix that should never appear tied to an external login. That pairing (encoded path + reserved user) is the single clearest tell of exploitation.

Credential & Cert Theft

The Manager stores device templates, API tokens and the certificates that underpin the SD-WAN control plane. Admin API access exposes this configuration repository, handing an attacker the keys to impersonate or re-enrol fabric components.

Fabric-Wide Config Push

netadmin can author and deploy templates and policies to every WAN Edge router in the overlay. A malicious policy can reroute traffic, open management access, or disable controls across hundreds of branch sites at once.

Persistence

New administrative accounts, modified RBAC, or tampered templates survive a session logout and can re-establish access even after the original request is blocked — which is why patching alone is not a compromise cleanup.

Availability Impact

The CVSS vector rates integrity and availability as High for good reason: a hostile operator can push configuration that partitions or bricks the overlay, turning a controller compromise into a WAN-wide outage.

SD-WAN Managers are meant to be reached by operators and by WAN Edge devices — not by the open internet. In practice, many deployments expose the web/API interface publicly for remote administration, cloud-hosted overlays, or because branch devices call home over untrusted links. Any such instance on a vulnerable build is a one-request compromise. Treat reachability, not just version, as the risk driver: an unpatched Manager behind strict management ACLs is materially safer than a patched-but-exposed one left on a lagging node.

• 1Collect admin-tech bundles first. Gather an admin-tech from every Manager instance — all cluster members and any DR site — before upgrading, so the pre-patch log state is captured.
• 2Grep the service-proxy and server logs for encoded j_security_check requests and viptela-reserved- user mappings (queries in Phase 09).
• 3Upgrade all nodes to the fixed release for their train. There is no workaround, so this is mandatory, not optional.
• 4Open a Cisco TAC case (reference CVE-2026-76504) and upload the admin-tech bundles so Cisco can scan them for compromise indicators.
• 5If compromise is confirmed, follow TAC-provided remediation, rotate all credentials and certificates managed by the controller, and audit administrative accounts and templates for unauthorised changes.
• 6Reconstruct the timeline: correlate the first encoded-request log entry with downstream config-change and account-creation events to scope what the attacker touched.

Finds any request to the form-auth endpoint that contains percent-encoding in the path — the core signature of the bypass, independent of which character was encoded.

Finds the smoking gun — an authentication event mapped to a viptela-reserved- internal account, which should never occur for an external login.

Finds encoded security_check requests that returned HTTP 200 from a source outside your management network — i.e. a request that likely succeeded in establishing a session.

When logs are not centralised, run these directly on each Manager against the paths Cisco specified. The second command surfaces the high-fidelity reserved-user pairing.

A generic Sigma rule you can convert to your backend for the encoded-endpoint signature. Keep the condition on the encoding pattern, not a single character.

There is no workaround. Upgrade every Manager node to the fixed release for its train (Phase 03), including cluster members and DR sites. For builds older than 20.9, migrate to a fixed release rather than waiting for a backport.

• 1Restrict management access to the Manager's web/API interface to a defined set of administrative prefixes with ACLs or a management VRF — do not expose it to the open internet.
• 2Cloud-hosted customers: review Allowed Inbound Rules under SSP > Overlay Details and tighten them to required source prefixes only.
• 3Front the interface with a VPN or jump host so administrative access requires a prior authenticated channel.
• 4Apply the Cisco Catalyst SD-WAN Hardening Guide baseline and review it after every major upgrade.
• 5Forward Manager logs (serviceproxy-access.log, vmanage-server.log) to your SIEM so the Phase 09 detections run continuously, not just during incident response.