Two Parsers, One URL: The Interpretation-Conflict Bug Is Eating Authentication in 2026

The most important character in this week’s Cisco advisory is the letter j.

CVE-2026-76504, the CVSS 9.8 authentication bypass in Catalyst SD-WAN Manager that Cisco confirmed as exploited and CISA put in KEV on September 30, does not involve memory corruption, a deserialization gadget, or a stolen credential. Cisco’s own indicator of compromise is a request for /%6a_security_check instead of /j_security_check. One percent-encoded letter. The authentication rule looked for the string it expected, did not find it, and waved the request through. The application then decoded the path, recognized it, and served the admin API.

That is not a one-off. It is the interpretation-conflict class (CWE-436, plus CWE-177 and friends), and in 2026 it has become the most productive way to turn an internet-facing control plane into someone else’s. My position: this is no longer a stream of unrelated bugs. It is a structural property of how we build authenticated systems out of stacked components, and patching individual CVEs will not make it stop. Engineers who own edge and management infrastructure need to treat “two components parse the same URL” as a design smell to be removed, not a bug to be waited on.

The pattern in one diagram

Every instance this year has the same shape:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

            raw request
                |
        +-------+--------+
        |                |
   [ gatekeeper ]   [ dispatcher ]
   "is this path    "which handler
    protected?"      runs?"
        |                |
  sees string A     sees string B
        |                |
   -> "public"      -> /admin API

The gatekeeper (a reverse-proxy rule, a servlet filter, a framework middleware, an SDK route matcher) answers a yes/no question about the request. The dispatcher (the router, the servlet mapping, the upstream proxy selection) decides what code runs. If those two components do not canonicalize the input identically, the attacker gets to pick a spelling that satisfies the first and means something else to the second. Neither component is individually wrong. The vulnerability lives in the seam.

Four case studies from one year

Cisco SD-WAN Manager (CVE-2026-76504, September). Per Cisco and public analysis, the rule gating the API’s session-based authentication matched the raw path, while request handling decoded it first. Replace j with %6a and the request skips the rule and executes with admin privileges. No workaround exists; the fix is an upgrade (fixed trains include 20.9.10.1, 20.12.8.2 and 20.15.6.1; Cisco’s managed cloud was already patched). Cisco’s detection guidance is to search serviceproxy-access.log and vmanage-server.log for j_security_check entries from unexpected sources, particularly the encoded form. Admin API on the Manager is control of the overlay: templates and policy pushed to every edge router, users and API keys for persistence, certificates and inventory for the whole fabric.

UniFi OS Server (CVE-2026-34908/34909/34910, disclosed May, KEV June 23). Bishop Fox found that the Nginx authentication handler evaluated the raw, percent-encoded URI when deciding whether a route needed auth, while upstream proxy selection used the normalized URI. Prefix a request with an auth-exempt path (/api/auth/validate-sso/), embed an encoded traversal sequence, and the gate sees “exempt” while the proxy routes to a fully authenticated internal API. A third CVE in the chain, command injection through an unsanitized package name, turned the bypass into unauthenticated root. All three scored 10.0 and Mirai and Gaafgyt botnets were scanning for it. Same bug as Cisco, different vendor, different language, different decade of codebase.

Starlette “BadHost” (CVE-2026-48710, May). X41 D-Sec found that Starlette rebuilt the request URL by concatenating scheme, Host header and path, then re-parsing it. Inject /, ? or # into Host and the boundaries shift:

1
2

GET /admin HTTP/1.1
Host: example.com/health?x=

Routing still used the real request line and delivered the request to /admin. But request.url.path, which is what auth middleware reads, returned /health, a public path. Starlette sits under FastAPI, vLLM, LiteLLM, Ray Serve and a long tail of MCP servers, and MCP’s mandated unauthenticated discovery endpoints hand an attacker a ready-made public path. The bug needed a raw socket because ordinary HTTP clients normalize Host, which is partly why it survived so long.

Clerk createRouteMatcher (CVE-2026-41248, April). The matcher that decides “is this route protected?” for Next.js, Nuxt and Astro middleware normalized a crafted path one way while the framework’s router resolved it another. If the matcher says no, clerkMiddleware() never runs the auth check. Sessions and cookies were not forgeable; the check was simply never invoked. Apps that treated the middleware match as their only gate, which is the documented pattern, were reachable.

Four vendors. Two appliance stacks, two application frameworks. One failure mode.

Why this keeps happening

Authentication is bolted on at a layer that does not own routing. The cheapest place to add “require login for these paths” is a string or glob match in front of the thing that actually routes. That is a policy about names, enforced by something that does not control how names resolve. Path-based allowlists and denylists are the wrong primitive, but they are the one every proxy, filter and middleware API offers first.

Normalization is spread across more layers than anyone counts. A request to a modern appliance passes a load balancer or cloud front door, Nginx or Apache, a servlet container or app server, a framework router, and sometimes a sidecar. Each may decode percent-escapes, collapse .., treat ; as a path parameter, merge slashes, fold case, or rebuild a URL from headers. RFC 3986 gives the rules; real components implement dialects of them.

Testing does not cross the seam. Unit tests for the auth rule feed it the canonical path. Unit tests for the router feed it the canonical path. Integration tests use a well-behaved HTTP client, which, as BadHost shows, normalizes before sending. The bug exists only for inputs no test author thought a client would send, and scanners that send well-formed requests will not find it.

Management planes are where the seam is thickest and the scrutiny thinnest. SD-WAN controllers, mail gateways, backup consoles and network managers are assembled from legacy Java, Perl, Nginx fragments and newer REST layers. They also hold the keys: fabric configuration, mail flow, directory bind credentials. That combination, high value and layered parsers, is why this class concentrates in appliances. FortiMail’s CVE-2026-104286, exploited as a zero-day and also a web-interface path traversal (CWE-22) with no fixed builds on the main release branches at disclosure, is the same family: user-controlled path text reaching a place its author assumed it could not.

What I would stop believing

1. “The auth check is in front of everything.” It is in front of everything as the checker spells it. Ask what the next component calls the same request.
2. “No workaround, so it’s a patch-window problem.” Cisco listed none for 76504. Teams with the management plane reachable from the internet had nothing to do but upgrade. Teams with it on a management VRF behind an allowlist had already reduced the exposure to near zero. Network position was the only control that worked pre-patch.
3. “A WAF will catch it.” One percent-encoded letter is a legitimate request to a WAF that decodes the same way the gatekeeper does and a bypass to one that does not. A WAF is a third parser, which makes the problem a little worse.
4. “We run scanners, so we’d know.” Scanners send canonical requests.

What to do about it

Remove the exposure first

None of the above is exploitable by an attacker who cannot reach the listener. Management and API ports for SD-WAN managers, mail gateways, hypervisor managers and backup servers belong on a dedicated management network or behind a VPN with allowlists. This is the one control that worked against 76504 and FortiMail before patches existed. If a vendor tells you “no workaround,” your workaround is the network.

Make one component authoritative

When you build or configure the stack, enforce this rule: the component that authorizes must be the component that routes, or must consume the router’s output rather than the raw input.

• Do authorization inside the handler or in framework-level route metadata (decorators, per-route guards), not in a string match in front of it.
• If you must gate at a proxy, normalize first and fail closed on anything non-canonical. In Nginx, location matching already operates on a normalized URI, but values you capture or pass through variables such as $request_uri are raw. Never make an auth decision on $request_uri and route on $uri, or the reverse.
• Default-deny. An allowlist of public paths with everything else authenticated fails safe when parsers disagree on the unknown; a denylist of protected paths fails open.
• Treat middleware match results as advisory. For Clerk-style setups, put an explicit auth check in each protected handler as well. Defense in depth here means the same decision made twice by code that does not share a parser.

Reject non-canonical requests at the edge

Most legitimate clients never send an encoded unreserved character (%41-%5A, %61-%7A, %30-%39, %2D, %2E, %5F, %7E), a doubled slash, a dot-segment, or a Host header containing /, ?, # or @. A rule that rejects them with a 400 breaks almost nothing and kills this class wholesale. Test it against your real traffic first. The Nginx pattern below returns 400 on encoded unreserved characters in the raw request line:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# http{} context: flag raw URIs that percent-encode unreserved characters
map $request_uri $noncanonical_uri {
    default 0;
    "~*%(?:4[1-9a-f]|5[0-9a]|6[1-9a-f]|7[0-9a]|3[0-9]|2[de]|5f|7e)" 1;
}

server {
    if ($noncanonical_uri) { return 400; }
    if ($host ~ "[/?#@]")   { return 400; }
}

Treat that as a starting point, not a drop-in. if in Nginx has sharp edges, and some applications legitimately encode characters in query strings, which is why the map targets only the path portion in a real deployment. Validate in a staging path and log-only mode before enforcing.

Hunt for it in logs you already have

Detection is cheap because the exploit leaves an unmistakable raw-URI artifact, if the log records the raw URI. Confirm yours does, since some stacks log the decoded path.

1
2
3
4
5
6
7
8

# Cisco's published pattern for 76504 (run on the Manager's logs)
grep -iE '%6a_security_check|j%5fsecurity|%6a%5f' serviceproxy-access.log vmanage-server.log

# Generic: encoded unreserved characters in any access log
grep -E '"(GET|POST|PUT|DELETE) [^" ]*%(4[1-9A-F]|5[0-9A]|6[1-9A-F]|7[0-9A]|3[0-9]|2[DE]|5F|7E)' access.log

# Generic: Host header abuse (needs a log format that records $http_host)
grep -E 'host="[^"]*[/?#@]' access.log

Any hit from an address you do not recognize on a management plane is an incident, not a finding. For SD-WAN, review recent template and policy pushes, new users and API keys, and certificate changes in addition to the access log, because the damage from admin API access is configuration, not malware.

Add the seam to your test suite

Write the adversarial test your vendor did not. For every protected route in an application you own, send the same request in several spellings (encoded letters, %2F, ..;/, double slashes, trailing dots, mixed case, hostile Host) over a raw socket, and assert the response is identical to the canonical unauthenticated request: a 401 or 403 every time. This is an afternoon of work and a loop in a CI job.

Change how you buy

Ask vendors, in security questionnaires, how authentication decisions are made relative to routing, whether the product normalizes before authorizing, and whether the management plane can be bound to a dedicated interface. Fortinet, Cisco and Ubiquiti all shipped this class in 2026, so brand is a poor predictor. Answers to those questions are a better one. Prefer products that ship the management plane off by default on data interfaces.

Takeaways

• Interpretation conflict is the dominant authentication-bypass pattern of 2026. Cisco, Ubiquiti, Starlette and Clerk are the same bug in four places. Expect more.
• Network position beats patch speed for appliances with “no workaround” advisories. Unreachable management planes were safe on day zero.
• Authorize where you route. If that is impossible, normalize first, default-deny, and fail closed on non-canonical input.
• Reject the weird requests. Encoded unreserved characters, dot-segments and hostile Host headers have no business reaching a control plane.
• Log the raw URI, and grep it. The signature of this class is visible in logs most teams already collect.
• Test the seam, over a raw socket, with spellings your auth rule has never seen.

The letter j was never the vulnerability. The vulnerability was two pieces of software that each believed they knew what the request said.

Sources

• Cisco PSIRT advisory for CVE-2026-76504 and coverage by SOC Prime and SOCRadar
• Fortinet PSIRT FG-IR-26-099 (FortiMail CVE-2026-104286)
• Bishop Fox research on UniFi OS Server (SAB-064)
• X41 D-Sec / OSTIF audit advisory for Starlette CVE-2026-48710
• Clerk advisory GHSA-vqx2-fgx2-5wq9