Hunt Cisco SD-WAN Manager CVE-2026-76504: the encoded login
You are reading the access log on a Catalyst SD-WAN Manager and one line is wrong in a quiet way. A POST returned 200 from an address nobody on your team recognizes, and the login path is spelled slightly off. Instead of j_security_check it reads %6a_security_check. An admin API session now exists that nobody opened on purpose.
That is the shape Cisco published as its example for CVE-2026-76504, an API authentication bypass in Cisco Catalyst SD-WAN Manager (formerly vManage). Cisco's PSIRT says it became aware of active exploitation in September 2026, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on 30 September 2026 as "Cisco Catalyst SD-WAN Manager Hex Encoding Vulnerability."
Keep three questions in mind as you read. Which of your Managers can the internet reach? Is serviceproxy-access.log kept anywhere besides the Manag eri tself? And would a patch tell you about a session someone opened last week?K
How the attack works
The gate checks the string, not what the string means
Cisco describes a flaw in the API session-based authentication management of the Manager. The software handles URI encoding in an HTTP request improperly, which lets a request bypass an authentication rule meant to restrict access to a specific API endpoint. An unauthenticated remcker who sends a crafted request to the API reaches it with the privileges of the admin user. Cisco scores it CVSS 3.1 9.8, under advisory cisco-sa-sdwan-webauth-xr8beuuU.
Percent encoding is a normal part of URLs, and %6a is simply the letter j. A rule that asks "is this the protected path?" can say no to the encoded spelling while the application behind it reads the same request as the protected path. The gate compared identity (the characters it received) and never reached authority (the resource the request means).
Cisco says its example is only an example: any one character encoded in the request can be used. A hunt for the single string %6a_security_check finds one spelling out of many. Cisco also says the flaw affects the Manager regardless of system configuration, so no configuration exempts you.
Risk: what the Manager holds
The Manager is the control plane for an SD-WAN edge fleet, and this bug hands an unauthenticated caller its admin API. Cisco says Managers that are exposed to the internet, with ports exposed, are at risk of compromise. Treat those as the clearest exposure.
Cisco does not say who is exploiting this, whom they targeted, or what they did afterward, and CISA's KEV listing rests on evidence of active exploitation. Beyond that, this post does not guess.
Mitigate and reduce risk
Cisco's guidance first:
Upgrade to the first fixed release for your train: 20.9.10.1, 20.12.8.2, 20.15.6.1, 20.18.4.1, 26.1.2.1, or 26.2.1. Earlier than 20.9, migrate to a fixed release.
No workaround addresses the vulnerability. As an interim mitigation for on-prem, restrict access from unsecured networks such as the internet. If internet access is required, allow only known, trusted hosts on the ports and protocols in the user guides.
Cisco has also released a Live Protect shield for CVE-2026-76504 as temporary partial protection while you plan the upgrade. It is not a fix. Upgrading to a fixed release is still the only remediation.
Put the control components behind a firewall that allows only known, trusted hosts, and filter traffic to and from them. Cisco asks you to validate any mitigation in your own environment first.
Cisco SD-WAN Cloud (Cisco Managed) is already on fixed Release 20.15.605. No customer action is required.
If you suspect compromise, run request admin-tech on the Manager, then open a Severity 3 TAC case with CVE-2026-76504 in the title.
A patch closes the door but does not check the rooms. That is our reading, not a Cisco statement for this CVE, so review admin accounts and configuration changes from the exposure window.
General-knowledge controls, all test first:
Forward Manager logs off the box, so an intruder with admin cannot trim the only copy. Cisco also recommends external logging.
Alert on admin API success from outside your management ranges.
Check from outside your firewall what reaches each Manager, not just from the config.
How to hunt the activity
These hunts use only the two log paths Cisco published: /var/log/nms/containers/service-proxy/serviceproxy-access.log and /var/log/nms/vmanage-server.log. Start with inventory: list every Manager, note which answer from the internet, and confirm both logs are forwarded.
All four queries are our own, and every field name is test first against a known event from your Manager. Cisco warns these indicators can occur during standard operations, so read matches as leads. The table under the hunts, "Interpret before you escalate", says what is benign and what is not.
Hunt in Splunk: j_security_check variants in serviceproxy-access.log
index=YOUR_MANAGER_INDEX source="*serviceproxy-access.log"
| rex field=_raw "\"(?<method>[A-Z]+) (?<uri>\S+) HTTP/[\d.]+\" (?<http_status>\d{3}) \S+ \d+ \d+ \d+ \S+ \"(?<client_chain>[^\"]+)\""
| where match(uri, "(?i)(%[0-9a-f]{2}_security_check|j%[0-9a-f]{2}security_check|j_%[0-9a-f]{2}ecurity_check|j_s%[0-9a-f]{2}curity_check|j_se%[0-9a-f]{2}urity_check|j_sec%[0-9a-f]{2}rity_check|j_secu%[0-9a-f]{2}ity_check|j_secur%[0-9a-f]{2}ty_check|j_securi%[0-9a-f]{2}y_check|j_securit%[0-9a-f]{2}_check|j_security%[0-9a-f]{2}check|j_security_%[0-9a-f]{2}heck|j_security_c%[0-9a-f]{2}eck|j_security_ch%[0-9a-f]{2}ck|j_security_che%[0-9a-f]{2}k|j_security_chec%[0-9a-f]{2})")
| table _time host method uri http_status client_chain
| sort 0 _timeField mapping: the rex follows Cisco's example line, and the extracted names are ours (test first). The regex covers one encoded character anywhere in the string. Confirm which address in the quoted chain is the true client.
False positives: plain j_security_check appears in ordinary logins, so this keeps only encoded spellings. Scanners or odd clients you own can still match.
Empty result: confirm the file is forwarded and retention covers September. Empty can mean no data.
Hunt in Kibana: vmanage-server.log and the viptela-reserved accounts
log.file.path: "/var/log/nms/vmanage-server.log"
AND message: *security_check*
AND message: *viptela-reserved-*Then isolate the exact encoded form from Cisco's published example, a percent-encoded first character:
log.file.path: "/var/log/nms/vmanage-server.log"
AND message: *%*_security_check*
AND message: *viptela-reserved-*Kibana's search language cannot express the full sixteen-variant pattern the way the Splunk, Falcon, and KQL regexes do, so read the broad results by eye for % encodings in other positions. The tightened query catches the published example form.
Field mapping: log.file.path and message are ECS names that depend on how you ship the file (test first). Add @timestamp, host.name, and message as Discover columns. Cisco's example line reads "Request Stored in Map is" followed by the path and the user.
False positives: viptela-reserved- names are system service accounts that Cisco documents. Cisco's concern is entries tied to j_security_check from unknown or unauthorized addresses.
Empty result: check the file is shipped and parsed. A filter on a field that never populated returns nothing.
Hunt in Falcon CQL: who sent the encoded spellings, and how often
@rawstring = /"[A-Z]+ \S*(%[0-9a-f]{2}_security_check|j%[0-9a-f]{2}security_check|j_%[0-9a-f]{2}ecurity_check|j_s%[0-9a-f]{2}curity_check|j_se%[0-9a-f]{2}urity_check|j_sec%[0-9a-f]{2}rity_check|j_secu%[0-9a-f]{2}ity_check|j_secur%[0-9a-f]{2}ty_check|j_securi%[0-9a-f]{2}y_check|j_securit%[0-9a-f]{2}_check|j_security%[0-9a-f]{2}check|j_security_%[0-9a-f]{2}heck|j_security_c%[0-9a-f]{2}eck|j_security_ch%[0-9a-f]{2}ck|j_security_che%[0-9a-f]{2}k|j_security_chec%[0-9a-f]{2})\S* HTTP/[\d.]+" (?<http_status>\d{3})/i
| regex("\" \d{3} \S+ \d+ \d+ \d+ \S+ \"(?<client_chain>[^\"]+)\"", field=@rawstring)
| groupBy([client_chain, http_status], function=[count(as=hits), min(@timestamp, as=first_seen), max(@timestamp, as=last_seen)])
| sort(hits, order=desc)Field mapping: run it in the repository holding the forwarded serviceproxy-access.log. Falcon sees these requests only if you ingest the Manager's logs. The field names are ours (test first), and the time fields are epoch milliseconds.
False positives: a scanner you run will appear here. Compare client_chain with your scanner and management ranges.
Empty result: confirm ingestion and that the repository covers the window.
Hunt in KQL: unexpected admin API success from outside your ranges
For Sentinel or Defender-style workspaces where Manager logs arrive as syslog or in a custom table. This depends on your ingest, so swap in your table and column.
let StartTime = ago(30d);
let TrustedRanges = dynamic([]); // add your management CIDRs, e.g. "x.x.x.0/24"
Syslog
| where TimeGenerated >= StartTime
| extend Uri = extract(@'"[A-Z]+ (\S+) HTTP/', 1, SyslogMessage)
| where Uri matches regex @'(?i)(%[0-9a-f]{2}_security_check|j%[0-9a-f]{2}security_check|j_%[0-9a-f]{2}ecurity_check|j_s%[0-9a-f]{2}curity_check|j_se%[0-9a-f]{2}urity_check|j_sec%[0-9a-f]{2}rity_check|j_secu%[0-9a-f]{2}ity_check|j_secur%[0-9a-f]{2}ty_check|j_securi%[0-9a-f]{2}y_check|j_securit%[0-9a-f]{2}_check|j_security%[0-9a-f]{2}check|j_security_%[0-9a-f]{2}heck|j_security_c%[0-9a-f]{2}eck|j_security_ch%[0-9a-f]{2}ck|j_security_che%[0-9a-f]{2}k|j_security_chec%[0-9a-f]{2})'
| extend HttpStatus = extract(@'HTTP/[\d.]+" (\d{3})', 1, SyslogMessage)
| extend ClientChain = extract(@'HTTP/[\d.]+" \d{3} \S+ \d+ \d+ \d+ \S+ "([^"]+)"', 1, SyslogMessage)
| extend FirstClient = tostring(split(ClientChain, ",")[0])
| where HttpStatus == "200"
| where not(ipv4_is_in_any_range(FirstClient, TrustedRanges))
| project TimeGenerated, Computer, FirstClient, ClientChain, Uri, HttpStatus
| order by TimeGenerated ascField mapping: Syslog, Computer, and SyslogMessage are standard syslog columns, but whether Manager logs land there is your pipeline (test first). The Uri pattern is the same one-encoded-character match as the Splunk hunt.
False positives: with an empty TrustedRanges list every client looks untrusted, so fill it in first. Your own scanners can also match.
Empty result: confirm Manager logs reach the workspace and parse. Quiet logs and missing logs look the same.
Interpret before you escalate
Finding | Benign read | Escalate when |
Encoded spelling of the login path with 200, from an unrecognized address | A scanner or tool you run | The address is not yours and the request succeeded |
viptela-reserved- user in a vmanage-server.log line about the path | A system service account doing normal work | The same line pairs with an unknown address or an encoded spelling |
Plain j_security_check in the access log | An ordinary login | It follows an encoded attempt from the same address |
A Manager reachable from the internet | A deliberate, documented exception | Nobody can say why, or it is not yet on a fixed release |
Empty results | Nothing matched | Logs were never forwarded or retention is short, so fix coverage first |
Sources
Cisco, Cisco Catalyst SD-WAN Manager API Authentication Bypass Vulnerability, cisco-sa-sdwan-webauth-xr8beuuU (30 September 2026): https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-sdwan-webauth-xr8beuuU
CISA, CISA Adds One Known Exploited Vulnerability to Catalog (30 September 2026): https://www.cisa.gov/news-events/alerts/2026/09/30/cisa-adds-one-known-exploited-vulnerability-catalog
What This Means for Your Team
Find your Managers, then find out who can reach them. If any answers from the internet, close that path and schedule the upgrade to your train's fixed release. Run the hunts, and ask TAC for a review if a match looks real. A patch fixes the software and does not tell you what happened before it.
Inception Protection
Inception Protection is our managed detection and response service, and it works with the Microsoft licenses you already have. The Manager's logs reach us only if you forward them, so we start there. Then we read the access log, the server log, and the sign-ins around them as one story, and you keep the decisions.
Inception Foresight
If you want to see how well your Microsoft environment would surface a login like this, the free Inception Foresight M365 Assessment is a good place to start: https://www.inceptionsecurity.com/m365assessment. You can also follow Inception Security on LinkedIn and @inceptionsec on X.
