CVE-2026-48491 is a critical flaw (CVSS 10.0) in Traefik 3.7 that lets an unauthenticated client bypass mutual TLS on routers that use a wildcard host rule with stricter TLS options. It affects versions from 3.7.0 until the fix. Upgrade to Traefik 3.7.3, which fixes it.
What's affected
Traefik from 3.7.0 until 3.7.3. The GitHub advisory lists affected versions as 3.7.0 through 3.7.1 and the patched version as 3.7.3, while the NVD record says until 3.7.3, so treat anything below 3.7.3 as affected.
You are exposed only if you use a router with a wildcard host rule, such as a rule for all subdomains of your domain, with stricter TLS options on it, for example a requirement for verified client certificates. There must also be another, more permissive server name served on the same entrypoint. The advisory says this affects the regular HTTPS and HTTP/2 path and does not need HTTP/3.
The same 3.7.3 release also lists fixes for CVE-2026-48020 and CVE-2026-53622, so the upgrade covers more than this one issue.
How to check if you're exposed
Start with the version, then look at your configuration for the pattern above.
traefik version
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep -i traefik
docker ps --format '{{.Names}} {{.Image}}' | grep -i traefik
Then search your static and dynamic configuration for routers whose rule uses a wildcard host and that point at a TLS option with client authentication, such as RequireAndVerifyClientCert. Those are the routes that depended on the check that failed.
What to do now
- Upgrade every Traefik 3.7.x instance to 3.7.3 or later, following the migration guide linked in the release notes.
- List routers that use a wildcard host rule together with stricter TLS options, and note which entrypoints they share with permissive server names.
- After the upgrade, test from a client without a certificate that these routes still refuse the connection.
- If you cannot upgrade at once, add client certificate checks at the backend as well. This is our suggestion, not advisory guidance, and it only helps if the backend can verify certificates itself.
- Review access logs for requests to protected hosts from clients that did not present a certificate.
Why it matters
The classes are CWE-288, authentication bypass using an alternate path or channel, and CWE-807, reliance on untrusted inputs in a security decision. The advisory describes the root cause: Traefik has a check meant to stop domain fronting, which compares the TLS server name with the HTTP Host header. That check looked up TLS options by exact match only and never applied wildcard matching. So a request could finish its handshake under permissive options, then name a different host in the HTTP request and reach a backend that was meant to demand a client certificate.
The lesson reaches beyond Traefik. When two layers make the same decision with different rules, an attacker looks for the gap between them. Here the TLS layer understood wildcards and the HTTP layer check did not. The record does not mark this CVE as exploited in the wild, and it is not on the CISA Known Exploited Vulnerabilities list.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I do not use mutual TLS?
The advisory describes a bypass of stricter TLS options on wildcard routers, with client certificates as the example. If you have no such routers, the exposure is much smaller, but upgrading is still sensible.
Is Traefik 3.6 or older affected?
The advisory lists 3.7.0 and later. Wildcard TLS option handling for the v3 rule syntax is described as introduced in 3.7.
Sources
Last reviewed: 19 October 2026.
