Cisco has released emergency security updates for a critical authentication bypass vulnerability affecting Cisco Catalyst SD-WAN Manager, formerly known as vManage.
Tracked as CVE-2026-76504, the vulnerability carries a CVSS score of 9.8 and allows an unauthenticated remote attacker to bypass API authentication and access an affected SD-WAN Manager with admin-user privileges.
Vulnerability Overview
| CVE | CVE-2026-76504 |
| Product | Cisco Catalyst SD-WAN Manager |
| Severity | Critical |
| CVSS v3.1 | 9.8 |
| CWE | CWE-177 – Improper Handling of URL Encoding |
| Attack Vector | Network |
| Authentication Required | No |
| User Interaction | No |
| Impact | Authentication bypass with admin API privileges |
| Exploitation | Confirmed in the wild |
| CISA KEV | Yes |
| Workaround | None |
| Cisco Bug ID | CSCww79570 |
Cisco describes CVE-2026-76504 as a vulnerability in the API session-based authentication management of Catalyst SD-WAN Manager.
The issue results from improper handling of URI encoding in HTTP requests.
SD-WAN Manager normally enforces an authentication rule around a specific API authentication endpoint. However, an attacker can encode a character within the requested URI in a way that causes the request to be processed without the expected authentication restriction.
A specially crafted HTTP request can therefore bypass authentication and provide access to the API with the privileges of the admin user.
How the Authentication Bypass Works
Cisco’s published indicators provide additional detail about the underlying bypass.
The normal session authentication endpoint uses:
/j_security_check
Cisco observed requests in which a character in the path was URI encoded. One example is:
/%6a_security_check
Here, %6a represents the letter j.
The important detail for defenders is that %6a is only an example. Cisco warns that exploitation can work when any single character in the request is encoded, meaning detections should not look exclusively for the literal %6a_security_check string.
This makes broad detection of encoded variations of j_security_check more useful than simply blocking one known request pattern.
Active Exploitation
Cisco PSIRT became aware of active exploitation of CVE-2026-76504 during September 2026. The vulnerability itself was identified while Cisco was resolving a Technical Assistance Center support case.
Cisco has not publicly attributed the activity to a specific threat actor and has not disclosed the number or identity of organizations affected.
No campaign-level attacker infrastructure, malware families or post-exploitation payloads were included in Cisco’s initial advisory.
However, the exploitation evidence was sufficient for CISA to add CVE-2026-76504 to the Known Exploited Vulnerabilities catalog immediately after disclosure.
New Zealand’s National Cyber Security Centre also issued an alert on October 1 warning organizations that the vulnerability is being actively exploited and urging affected users to upgrade as soon as possible.
Indicators of Compromise and Threat Hunting
Cisco has published several useful artifacts for identifying potential exploitation.
Security teams should review:
/var/log/nms/containers/service-proxy/serviceproxy-access.log
for unexpected POST requests involving encoded variants of j_security_check, including requests resembling:
POST /%6a_security_check HTTP/1.1
Teams should also review:
/var/log/nms/vmanage-server.log
for requests involving j_security_check associated with usernames beginning with:
viptela-reserved-
Cisco warns that similar entries may also occur during legitimate operations, so these indicators must be correlated with source IP addresses and the organization’s expected network posture before being treated as evidence of compromise.
Defenders should not search only for %6a. Because any one character in the vulnerable request may be encoded, hunting logic should account for other URI-encoded variations of j_security_check.
Cisco has also released Snort rule 67179 in connection with the advisory.
Affected and Fixed Versions
Cisco Catalyst SD-WAN Manager is affected regardless of configuration. Cisco has released the following fixed versions:
| Cisco Catalyst SD-WAN Release | First Fixed Release |
| Earlier than 20.9 | Migrate to a fixed release |
| 20.9 | 20.9.10.1 |
| 20.12 | 20.12.8.2 |
| 20.15 | 20.15.6.1 |
| 20.18 | 20.18.4.1 |
| 26.1 | 26.1.2.1 |
| 26.2 | 26.2.1 |
Cisco has separately patched its cloud-based Cisco SD-WAN Cloud (Cisco Managed) service in release 20.15.605 and says no customer action is required for that service.
Recommended Actions
Organizations operating Cisco Catalyst SD-WAN Manager should:
- Upgrade immediately to the appropriate fixed release rather than waiting for a normal maintenance cycle.
- Identify any SD-WAN Manager interfaces or ports reachable from the public internet and restrict access wherever possible.
- Until upgrading is complete, allow access only from known and trusted hosts and place SD-WAN control components behind appropriate filtering devices.
- Hunt historical serviceproxy-access.log data for encoded variants of j_security_check originating from unexpected or unauthorized addresses.
- Review vmanage-server.log for suspicious j_security_check activity involving viptela-reserved- system accounts.
- Review activity following suspicious authentication events for newly created accounts, privilege changes, configuration modifications and other unexpected administrative API actions.
- Ensure relevant SD-WAN logs are retained externally where possible so that historical exploitation can still be investigated.
- If compromise is suspected, generate an admin-tech bundle using the request admin-tech command and open a Cisco TAC case with CVE-2026-76504 in the title for further analysis.
Cisco specifically recommends restricting internet exposure of SD-WAN control components and filtering traffic so that only trusted hosts can reach the systems. These controls are mitigations rather than substitutes for upgrading.
Stay Safe. Stay Secure.
OP Innovate Research Team
