CVE-2026-48491: Domain-fronted mTLS bypass in Traefik SNICheck wildcard TLSOptions

I reported a domain-fronting mTLS bypass in Traefik that was published as CVE-2026-48491 / GHSA-5r4w-85f3-pw66.

The issue affected wildcard router TLSOptions on the regular HTTPS/HTTP2 path. A protected wildcard route could require client certificates for direct access, but an unauthenticated client could use a permissive SNI for the TLS handshake and then send an HTTP request authority / Host value targeting the wildcard-protected backend.

Advisory

• CVE: CVE-2026-48491
• GitHub Advisory: GHSA-5r4w-85f3-pw66
• Package: Traefik
• Ecosystem: Go module
• Affected versions: >= v3.7.0, <= v3.7.1
• Patched version: v3.7.3
• Severity: High 7.8/10
• CVSS: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N
• CWE: CWE-288: Authentication Bypass Using an Alternate Path or Channel

Root Cause

Traefik has protection against domain fronting. The intended behavior is that if the TLS SNI and the HTTP Host header resolve to different TLS options, Traefik should reject the request with 421 Misdirected Request.

That matters for mTLS. If api.example.com requires client certificates but public.example.net does not, a client should not be able to handshake as public.example.net and then route a request to api.example.com.

The vulnerable case involved wildcard TLS options.

The router could associate a wildcard host rule with strict TLS options:

http:
  routers:
    protected:
      rule: Host(`*.example.com`)
      service: protected
      tls:
        options: mtls

The later HTTP router understood that api.example.com matched *.example.com.

SNICheck did not use the same wildcard-aware lookup. It resolved the TLS option name for the HTTP host by checking exact host keys, lower-case variants, and trailing-dot variants. It did not resolve api.example.com against *.example.com.

As a result, the protected wildcard host could be classified as default inside SNICheck.

Attack Shape

The vulnerable deployment shape was:

1. A wildcard router such as Host("*.example.com") uses router-specific TLSOptions.
2. Those TLS options require client certificate authentication.
3. Another host or default TLS path on the same entrypoint allows a handshake without a client certificate.
4. The client can send an HTTP request authority / Host value different from the TLS SNI.

The exploit path was:

TLS SNI: public.example.net      -> permissive/default TLS options
HTTP Host: api.example.com       -> wildcard protected router

Direct access to api.example.com without a client certificate failed, as expected.

The domain-fronted request completed the TLS handshake under public.example.net, then routed the HTTP request to api.example.com. Because SNICheck classified both sides as default, it did not return 421. The request reached the backend protected by the wildcard route.

The negative control was important: replacing the wildcard rule with exact Host("api.example.com") made the same domain-fronting request fail with 421 Misdirected Request. That isolated the bug to wildcard TLSOptions resolution, not to a total failure of domain-fronting protection.

Impact

The impact is an authentication bypass for deployments that use wildcard router TLSOptions to enforce mTLS.

In affected deployments:

• direct access to the wildcard-protected host requires a client certificate;
• a permissive SNI on the same entrypoint can complete the TLS handshake without one;
• the HTTP request can still be routed to the wildcard-protected backend;
• the backend receives traffic that should have been blocked by mTLS.

The issue is deployment-dependent. It requires both a protected wildcard route and another permissive TLS path on the same entrypoint. When those conditions exist, the attack is remote, unauthenticated, and does not require HTTP/3.

Relationship To The HTTP/3 Issue

This issue is related to CVE-2026-53622, but it is not the same bug.

CVE-2026-53622 affected HTTP/3 TLS configuration selection. It was caused by the QUIC/TLS callback using exact SNI lookup before the HTTP router saw the request.

CVE-2026-48491 affected the regular HTTPS/HTTP2 path. It was caused by SNICheck resolving tlsOptionsForHost without wildcard matching during domain-fronting validation.

The impact is similar, but the vulnerable code path and the mitigation logic are different. Fixing only the HTTP/3 selector would not fix this SNICheck wildcard-resolution issue.

Why This Was Subtle

The public symptom could look like a routing edge case, not a security bug.

There was already public evidence that wildcard hosts could be classified as default by SNICheck, causing unexpected 421 responses in some setups. The security-relevant variant was the opposite failure mode: a false negative.

In the vulnerable flow, SNICheck should have detected that:

• the SNI resolved to permissive/default TLS options;
• the HTTP host resolved to wildcard mTLS options.

Instead, both sides could be classified as default, so the request was allowed.

That is why the bug is best understood as a consistency failure between wildcard-aware routing and exact-match security metadata lookup.

Fix Direction

The fix needs to make SNICheck resolve host TLS options with the same wildcard-aware semantics used by router host matching.

Defensive principles:

• domain-fronting checks should compare the security policy that the router would actually apply;
• wildcard Host / HostSNI mappings must not collapse to default during security checks;
• exact-host controls should be covered by tests alongside wildcard-host controls;
• deployments relying on mTLS should avoid weaker fallback TLS options on the same entrypoint unless the routing and SNICheck behavior is known to be patched.

References

• GitHub Advisory: https://github.com/traefik/traefik/security/advisories/GHSA-5r4w-85f3-pw66
• Traefik project: https://github.com/traefik/traefik