CVE-2026-48491: 
NixOS vulnerability analysis and mitigation

CVE-2026-48491 is a high-severity authentication bypass vulnerability in Traefik's SNICheck domain-fronting protection mechanism, allowing unauthenticated clients to bypass mutual TLS (mTLS) enforced through wildcard router TLSOptions. It affects Traefik versions 3.7.0 through 3.7.2 (fixed in 3.7.3). The vulnerability was first published by the GitHub Advisory Database on June 5, 2026, and formally disclosed on June 16, 2026. It carries a CVSS v3.1 base score of 10.0 (Critical) and a CVSS v4.0 base score of 7.8 (High) (GitHub Advisory, Traefik Release).

The root cause is classified under CWE-288 (Authentication Bypass Using an Alternate Path or Channel) and CWE-807 (Reliance on Untrusted Inputs in a Security Decision). The flaw resides in pkg/middlewares/snicheck/snicheck.go, where the findTLSOptionName function resolves TLS options for the HTTP Host header using only exact map lookups — it never performs wildcard matching. When a router is configured with a wildcard rule such as Host(*.example.com) and strict TLS options like RequireAndVerifyClientCert, the SNICheck middleware fails to associate the wildcard TLS policy with incoming requests whose Host header matches the wildcard pattern. An attacker exploits this via domain fronting: they complete the TLS handshake using a permissive SNI (e.g., public.example.net) served on the same entrypoint, then send an HTTP Host header targeting the wildcard-protected backend (e.g., api.example.com). Because SNICheck classifies the Host header as using default (permissive) TLS options, no 421 Misdirected Request is returned, and the HTTP router forwards the request to the mTLS-protected backend without verifying a client certificate. This issue affects HTTPS and HTTP/2 paths and does not require HTTP/3 (GitHub Advisory).

Successful exploitation allows an unauthenticated remote attacker to reach backends that are intended to be protected by mutual TLS client certificate authentication, completely circumventing the mTLS security boundary. The subsequent system impact is high for both confidentiality and integrity, as the attacker gains unauthorized access to protected services and their data without presenting any credentials. Deployments using wildcard router TLSOptions for client certificate-based access control — including Kubernetes Ingress setups — are at risk of exposing sensitive internal APIs or services to unauthenticated clients on the network (GitHub Advisory, Red Hat Bugzilla).

1. Reconnaissance: Identify Traefik instances running versions 3.7.0–3.7.2 that expose HTTPS/HTTP2 entrypoints. Look for deployments with wildcard router rules (e.g., Host(*.example.com)) configured with strict mTLS (RequireAndVerifyClientCert) alongside at least one permissive SNI on the same entrypoint.
2. Identify permissive SNI: Determine a hostname served on the same Traefik entrypoint that does not require a client certificate (e.g., public.example.net). This can be discovered via DNS enumeration, certificate transparency logs, or probing the entrypoint.
3. Establish TLS handshake under permissive SNI: Initiate a TLS connection using the permissive hostname as the SNI, completing the handshake without presenting a client certificate:

   curl --noproxy '*' --http2 -skv \
     --resolve public.example.net:8443:127.0.0.1 \
     https://public.example.net:8443/

4. Send domain-fronted request: Reuse the permissive TLS connection but override the HTTP Host header to target the wildcard-protected backend:

   curl --noproxy '*' --http2 -skv \
     --resolve public.example.net:8443:127.0.0.1 \
     https://public.example.net:8443/ \
     -H 'Host: api.example.com'

5. Access protected backend: SNICheck classifies the Host: api.example.com header as using default TLS options (due to missing wildcard matching), so no 421 is returned. The HTTP router matches the wildcard-protected backend and forwards the request, returning a 200 response from the mTLS-protected service without any client certificate (GitHub Advisory).

• Network: HTTP/2 requests where the TLS SNI (from the TCP/TLS layer) differs from the HTTP Host header or :authority pseudo-header; specifically, requests where the SNI resolves to a permissive/public route but the Host header targets a wildcard-protected domain (e.g., *.example.com subdomains).
• Logs: Traefik access logs showing successful HTTP 200 responses to wildcard-protected backends (e.g., api.example.com) from clients that did not present a client certificate; Traefik debug logs may show TLS option resolution falling back to default for wildcard host entries.
• Logs: Absence of TLS client certificate fields in access log entries for requests that should require mTLS; requests reaching mTLS-protected services with Host headers mismatched from the TLS SNI.
• Network: Unusual HTTP/2 traffic patterns where the :authority pseudo-header value differs from the server name used during TLS negotiation, observable via network inspection tools such as Wireshark or mTLS-aware proxies (GitHub Advisory).

Upgrade Traefik to version 3.7.3 or later, which resolves the wildcard matching gap in SNICheck by applying wildcard-aware host matching semantics consistent with the router/HostSNI matching logic (Traefik Release). If immediate upgrade is not possible, the following configuration-based workarounds can reduce exposure: (1) replace wildcard Host(*.example.com) rules with enumerated exact hostnames for mTLS-protected routes; (2) enforce mTLS in the default TLS options so all connections on the entrypoint require client certificates; (3) avoid mixing permissive and mTLS-protected hosts on the same entrypoint; or (4) block domain-fronted requests at an upstream layer (e.g., WAF or load balancer) (GitHub Advisory).

The Traefik maintainer team published a security update announcement covering this and two other CVEs fixed in version 3.7.3 via the Traefik community forum (Traefik Community). Red Hat tracked the vulnerability in its Bugzilla system and noted it as affecting Red Hat OpenShift Dev Spaces (Red Hat Bugzilla). The vulnerability was also picked up by FreeBSD's VuXML and openSUSE security announcement lists, indicating broad ecosystem awareness. No significant independent researcher commentary or social media discussion beyond standard CVE tracking has been identified.