How this bug class keeps getting shipped
Authentication bypass by URL encoding is one of the oldest tricks in the web application playbook, and it keeps generating critical-severity CVEs on appliances that anchor enterprise identity and segmentation. On 2026-09-30, CISA added CVE-2026-76504, an unauthenticated admin-equivalent bypass in Cisco Catalyst SD-WAN Manager, to the Known Exploited Vulnerabilities catalog. The vendor's own advisory, republished on 2026-10-04, describes the mechanism precisely: "improper handling of URI encoding in an HTTP request, which allows the request to bypass an authentication rule that is intended to restrict access to a specific API endpoint."
That one sentence is the whole bug class. We take CVE-2026-76504 apart as the lead example, then look briefly at the structurally identical failure in Cisco Secure Firewall Management Center (CVE-2026-20079), published the same day. Both are now in the window where defenders need to decide: patch, isolate, or assume compromise.
The parser disagreement, in one picture
The archetype is a web application fronted by two layers that must each parse the URL: an outer authentication filter and an inner request router. The filter decides which paths require a valid session; the router maps those paths to handlers. The bug is that the two layers disagree on what the URL is.
Consider a request path like /public/..%2fadmin/exportConfig. There are at least three plausible interpretations:
- Treat
%2fas an opaque byte in a path segment. The path is/public/..%2fadmin/exportConfig, which does not match/admin/*. The filter passes it through. - Decode
%2fto/before matching. The path is/public/../admin/exportConfig, which still does not match/admin/*as a prefix because the first segment ispublic. - Decode
%2fto/and then normalise... The path collapses to/admin/exportConfig. The router dispatches to the admin handler.
If the outer filter does step one and the inner router does step three, you have the exact shape of CVE-2026-76504. The vendor's language ("hex encoding vulnerability... improper handling of URI encoding") is the public giveaway. Attackers search for any percent-encoded or doubly-encoded sequence that reaches the back-end router intact but reads as plain text to the front-end rule.
A sketch of the probe shape, against an example.com placeholder:
GET /dataservice/..%2f..%2fdataservice/admin/user HTTP/1.1
Host: vmanage.example.com
Accept: application/json
GET /dataservice/client/..;/admin/user HTTP/1.1
Host: vmanage.example.com
GET /dataservice/%2e%2e/admin/user HTTP/1.1
Host: vmanage.example.com
Three variants, three different parser disagreements: percent-encoded slash, path parameter (;) injection, and percent-encoded dot. The CVE requires only one of these to reach the router unfiltered. Because the vulnerability is pre-authentication, the attacker needs only network reachability to the management plane. That is the most important mitigating control and the most commonly misconfigured one on an appliance that advertises a management UI.
What an exposed instance looks like
CISA has placed CVE-2026-76504 under BOD 26-04 (Prioritizing Security Updates Based on Risk), which carries forward the KEV remediation obligation from the superseded 22-01. Federal civilian agencies have a binding duty to remediate; everyone else has a strong signal that this is being used now by someone willing to burn it on indiscriminate scanning.
Three verification steps that do not require vendor telemetry:
- Confirm whether your Catalyst SD-WAN Manager management interface answers an unauthenticated HTTP request from outside your admin VLAN. If the TCP handshake completes from an untrusted network, the bug is reachable regardless of patch level.
- Audit reverse-proxy and WAF rules that gate
/dataservice/*or similar admin APIs. Any rule written as a literal string match on a decoded path is suspect; rules should normalise first and match second. - Pull access logs for the admin API endpoints and search for
%2e,%2f,..;, and double-percent sequences in the raw path. Benign clients do not emit these. A single hit, especially one that returned a 200 with a response size consistent with a successful admin operation, is a credible compromise indicator.
The patch is non-negotiable: there is no configuration workaround for a parser-disagreement bug. You cannot WAF your way out of it reliably, because the WAF is just another parser that will disagree with the application.
Same bug class, published the same day: CVE-2026-20079
Cisco's 2026-10-04 batch includes CVE-2026-20079, rated critical, in Secure Firewall Management Center Software. The vendor describes it as "an improper system process that is created at boot time" allowing an unauthenticated attacker to "bypass authentication and execute script files on an affected device to obtain root access to the underlying operating system." The attack vector is "crafted HTTP requests."
The surface detail differs (a boot-time process creates a reachable script execution path), but the exploitation shape mirrors CVE-2026-76504: an HTTP-reachable component holding privilege the authenticating layer never intended to expose. The vendor advisory describes CVE-2026-20079 as published, not exploited. That matters. The defensive response is still immediate patching, but the public evidence is "this is reachable and critical," not "this is being used right now in the wild." Confusing the two is how incident response budgets get burned on the wrong fires.
Both bugs are instructive about what gets shipped. The authentication filter and the privileged handler were written by the same company, probably by the same team, and still disagreed about the shape of a URL or a boot-time execution path. That is not a vendor-specific failing. It is what happens whenever a security boundary is enforced by matching strings against a request that another component will interpret differently.
What to do before the next one
Three durable practices, independent of this week's CVE list:
- Make management planes unreachable from untrusted networks by default. The strongest mitigation for pre-authentication HTTP bugs is not patching speed; it is that the attacker cannot send the request at all.
- Where you must expose management APIs, require that any authentication rule canonicalise the request path (percent-decode, normalise
.., strip path parameters) before matching, and reject requests whose canonical form differs from the raw form rather than silently normalising them. - Treat every KEV addition as a reachability audit, not just a patch task. The patch closes one door; the reachability review tells you how many doors of this shape you still have.
Verifiable security.