Advisory · CVE-2026-114635
Traefik SNI check is skipped when TLS state is nil on Go 1.27 builds, bypassing client certificate routers
Traefik before 2.11.58 and 3.7.14 skips its SNI check when request TLS state is nil, which happens for HTTP/2 requests with the http scheme pseudo-header on Go 1.27 builds, so unauthenticated clients can reach routers requiring client certificates without presenting one. Official builds use Go 1.26 and are not exposed, per the Traefik advisory. CVSS 3.1 8.7.
- Vendor
- Traefik
- Product
- Traefik
- Identifier / CWE
- CVE-2026-114635
CWE-288 - Action timing
- Immediate
Explain it like I’m five
The guard who checks whether your connection matches the room you asked for takes a break when the paperwork is blank, and on certain builds the paperwork arrives blank, so anyone can walk into rooms that were supposed to require a client certificate.
- 01Attacker opens a TLS connection
An unauthenticated client connects to Traefik over TLS on a build made with Go 1.27.
- 02HTTP/2 request carries no TLS state
The client sends an HTTP/2 request with the http scheme pseudo-header, which leaves the request TLS state unset on those builds, per the Traefik advisory.
- 03SNI check is skipped
Traefik skips the SNI check entirely when the request carries no TLS connection state.
- 04Protected router serves the request
The request is served by a router with different TLS options, for example one requiring a client certificate, without the client presenting one.
What happened
Traefik disclosed CVE-2026-114635 in its GitHub security advisory: the SNI check, which makes sure a request received on a TLS connection is only served by an HTTP router whose TLS options match the ones negotiated for that connection, was skipped entirely when the request carried no TLS connection state. Traefik states that builds made with Go 1.27 leave that state unset for HTTP/2 requests sent with the http scheme pseudo-header over a TLS connection, so an unauthenticated client could be served by a router with different TLS options, for example one requiring a client certificate, without presenting one. The CVSS 3.1 score is 8.7, with network attack vector, high complexity, no privileges, no user interaction, and changed scope.
Traefik states that official Traefik binaries and images are built with Go 1.26 and are not exposed, but any Traefik build made with Go 1.27, including third-party rebuilds, is exposed. The patched releases are 2.11.58 and 3.7.14. Traefik also states that v3 versions below v3.7 are affected but no longer maintained and will not receive a patch of their own, so the remedy for those users is to upgrade to a maintained, patched version. Traefik says it now always sets the TLS state of requests received on a TLS connection, so the check applies whatever the toolchain.
What to do
- Inventory Traefik deployments and, critically, how each binary or image was built: official images built with Go 1.26 are not exposed per Traefik, while custom or third-party builds made with Go 1.27 are.
- Upgrade affected builds to Traefik 2.11.58 or 3.7.14 or later; deployments on unmaintained v3 lines below 3.7 must move to a maintained, patched release.
- Until custom builds are replaced, do not rely on client certificate requirements alone on routers served by Go 1.27 builds, and add network or middleware controls in front of sensitive backends.
- Hunt for HTTP/2 requests with the http scheme pseudo-header reaching client-certificate routers, and for access to those backends without a presented certificate.
- Verify the deployed version and build provenance on every Traefik instance after updating, including ingress controllers in Kubernetes clusters.
Management note
The exposure here is build provenance, not just version: official images are safe and quiet rebuilds are not. Know which Traefik binaries in your estate were built with Go 1.27 before deciding this one does not apply to you.