Traefik CVE-2026-114635

Exploitation requires three concrete conditions to all hold: (1) the Traefik binary is built with Go 1.27, which is the specific toolchain behavior that causes the request TLS state to be evaluated as nil; (2) at least one Traefik router is configured to require client certificates (mTLS) - routers without a client-cert requirement gain nothing; and (3) the attacker can reach the TLS listener and send an HTTP/2 request bearing the ':scheme http' pseudo-header over that TLS connection. No authentication, privileges, or user interaction are needed (PR:N/UI:N), but the Go 1.27 build dependency and the requirement that an mTLS-protected router actually exist are the primary limiting factors that keep this from being universally exploitable against default Traefik deployments.

This is a legitimate, moderately high-priority issue for environments that rely on Traefik mutual TLS (mTLS) as an authentication boundary, but it is narrower than a raw '7.0 CRITICAL-sounding' auth bypass. The input CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) confirms a network-reachable, unauthenticated attack (PR:N) with low complexity, but critically carries AT:P (Attack Requirement Present) - reflecting the explicit precondition that the binary is built with Go 1.27, which materially shrinks the exploitable population. The impact metrics are telling: vulnerable-system impact is None (VC:N/VI:N/VA:N) while subsequent-system impact is High for confidentiality and integrity (SC:H/SI:H) - i.e., Traefik itself is not compromised, but the mTLS-protected backend routers behind it are exposed to unauthenticated access, consistent with CWE-288 (authentication bypass by an alternate path). On exploitation signals: there is no CISA KEV listing and no public exploit identified at time of analysis, so this is not confirmed active exploitation; EPSS was not provided and SSVC fields were not supplied, so automatability and exploitation-status decision inputs are absent. Net: prioritize patching where client-certificate-protected routers exist AND the deployment runs a Go 1.27 build, but this is not evidence of widespread opportunistic exploitation. One data caveat to verify with the vendor: the condition 'on Go 1.27 builds' is a specific toolchain dependency that should be confirmed against your actual Traefik binary provenance before rating urgency.

An organization fronts an internal API with Traefik and enforces mTLS by configuring a router to require a valid client certificate. An unauthenticated attacker, able to reach the TLS listener, sends an HTTP/2 request carrying the ':scheme http' pseudo-header over the TLS connection; on a Go 1.27 build the request's TLS state is treated as nil, the SNI/client-certificate check is skipped, and the request reaches the protected router without any client certificate. No public exploit code has been identified at time of analysis, so exploitation would require an attacker to craft the HTTP/2 pseudo-header manipulation themselves.