Traefik vulnerabilities

Traefik is an open source HTTP reverse proxy and load balancer. From 2.11.26 until 2.11.57 and 3.7.13, Traefik forwards a client-supplied Connection header requesting Upgrade, the Upgrade: h2c token, and HTTP2-Settings to a shared backend. If the backend accepts h2c and returns 101 Switching Protocols, Traefik enters a raw tunnel and no longer applies routers, BasicAuth, ForwardAuth, IPAllowList, RateLimit, access logging, metrics, or tracing to later HTTP/2 requests, allowing an unauthenticated request through an unprotected route to reach protected paths on the same backend. This issue is fixed in 2.11.57 and 3.7.13.

Traefik (open source HTTP reverse proxy and load balancer) from 2.11.0 until 2.11.57 and 3.7.13 has an HTTP/3 issue: ConnContext does not call service.AddTransportOnContext, so kerberosRoundTripper uses a shared backend transport instead of one dedicated to each frontend connection. With HTTP/3 enabled, a backend using connection-bound NTLM or Negotiate authentication, and backend keep-alive, an unrelated client can reuse a backend connection authenticated for a victim, read victim-only data, and act as that victim without the victim credentials.

Traefik (HTTP reverse proxy and load balancer) in versions >= v3.7.0 and <= v3.7.11 has a flaw in the Kubernetes ingress-nginx provider for Ingresses carrying both an authentication annotation and the nginx.ingress.kubernetes.io/from-to-www-redirect annotation. The provider creates an additional 'sibling' router that matches on the host alone, carries only the RedirectRegex middleware, and still points at the parent router's protected backend service. Because RedirectRegex is not a terminal handler, a request its pattern does not match is forwarded to the backend, and because the redirect pattern only accepts a numeric port, a request with a non-numeric or empty port (e.g. 'Host: www.example.com:x') selects the sibling router, misses the redirect, and is proxied to the protected backend with none of the Ingress's annotation-derived middlewares applied. This discards not only authentication (e.g. BasicAuth) but every annotation-derived middleware, including source-IP allowlisting. Traefik v2 and v3 releases before v3.7.0 are not affected. The issue is fixed in v3.7.12.

Traefik before v2.11.55 and v3.0.0 through v3.7.10 contain a TLS option conflict resolution vulnerability that allows unauthenticated attackers to bypass client-certificate authentication by creating conflicting TLS options on multi-host routers. Attackers can reach protected backends by exploiting shared TLS resolution across multiple hostnames in a single router rule, causing the strict mTLS requirement to fall back to default options for all hosts.

Traefik versions >= v3.7.0 and <= v3.7.10 contain an authentication bypass in the Kubernetes Ingress NGINX provider. The TLS option generated for an Ingress carrying the nginx.ingress.kubernetes.io/auth-tls-secret annotation was named after the Ingress namespace and name. As a result, two Ingress objects sharing the same host, the same client CA secret, and the same client-authentication mode produced two distinct TLS option names for that host. Traefik treats this as a TLS options conflict and falls back to the entry point's default TLS configuration, which does not request a client certificate, so a route configured with nginx.ingress.kubernetes.io/auth-tls-verify-client: "on" becomes reachable without a client certificate. Only the v3.7 line is affected; the issue is fixed in v3.7.11.

Traefik versions before v2.11.55 and versions v3.0.0 through v3.7.10 contain an authentication bypass vulnerability in the digestAuth middleware where unknown usernames receive an empty secret instead of rejection. Attackers can compute a valid digest response using the empty secret and arbitrary credentials to bypass authentication on any digestAuth-protected route without a valid username or password.

Traefik versions from v3.7.1 fail to enforce crossProviderNamespaces restrictions on the traefik.ingress.kubernetes.io/service.middlewares Service annotation in the Kubernetes Ingress provider. A namespace-limited tenant excluded from the allowlist can attach an operator-owned middleware to its Service, and if that middleware injects backend credentials, recover them at a controlled backend.

Vulnerability in Traefik (before 2.11.53, 3.6.24, and 3.7.9) in the default HTTP reverse proxy. Forwarding CONNECT requests can lead to connection desynchronization, allowing an attacker to smuggle responses to another client.

In Traefik prior to versions v2.11.51, v3.6.22, and v3.7.6, the BasicAuth, DigestAuth, and ForwardAuth middlewares fail to strip underscore-variant identity headers that backends normalize to dashed forms. An attacker can inject such a header to spoof identity or bypass authorization.

Traefik versions prior to 3.7.3, 3.6.18, and 2.11.51 have a critical vulnerability in HTTP/3 (QUIC) TLS configuration selection that allows unauthenticated clients to bypass router-specific mTLS enforcement. When HTTP/3 is enabled, the TLS handshake selects the TLS configuration via exact, case-sensitive SNI lookup, failing to match wildcard host patterns or case variants. This allows clients to complete the QUIC handshake without presenting a certificate, while the HTTP routing layer still dispatches requests to protected backends.

In Traefik versions 3.7.0 through 3.7.3, a vulnerability in the domain-fronting protection (SNICheck) allows an unauthenticated client to bypass mutual TLS enforced by wildcard router rules. The attacker can complete a TLS handshake under permissive options for a different SNI and then send an HTTP request with a Host header targeting the wildcard-protected backend without presenting a client certificate.

In Traefik prior to versions 2.11.48, 3.6.19, and 3.7.3, a high severity vulnerability exists in the StripPrefix middleware. An unauthenticated attacker can bypass route-level authentication and authorization by using paths containing .. or %2e%2e, which after normalization resolve to protected resources.

A vulnerability in Traefik allows a user with HTTPRoute creation permissions in the Kubernetes Gateway API provider to bypass the providers.rest.insecure=false setting and access the REST provider handler. By accepting TraefikService backends with names ending in @internal, traffic can be routed to rest@internal, enabling unauthorized reconfiguration of routers and services in shared Gateway deployments.

A high severity authentication bypass vulnerability was found in Traefik's ForwardAuth and snippet-based authentication middleware. The issue stems from improper sanitization of header aliases using underscores instead of dashes, allowing an attacker to inject spoofed trust context and bypass authentication without valid credentials.

An authentication bypass vulnerability was found in Traefik's ForwardAuth middleware when trustForwardHeader=false is set and Traefik runs behind a trusted upstream proxy. The issue is fixed in versions 2.11.43, 3.6.14, and 3.7.0-rc.2.

In Traefik from 3.6.11 until 3.7.13, checkPassword in BasicAuth constructs the singleflight key from the submitted password and stored secret. Concurrent requests for absent usernames coalesce on one key while configured usernames perform separate password hashes, creating an unauthenticated timing discrepancy that reveals whether a username exists. Sequential checks remain cost-equalized, Traefik v2 and Digest authentication are not affected, and the issue does not disclose credentials or bypass authentication.

Traefik is an open source HTTP reverse proxy and load balancer. From 2.8.2 until 2.11.56 and 3.7.12, HTTP/3 entrypoints do not apply entryPoints..transport.respondingTimeouts.readTimeout because the timeout is enforced on a TCP connection and the HTTP/3 server has no corresponding QUIC stream deadline. An unauthenticated client can use a slow request body, trickling data indefinitely while holding a request and an upstream connection open and exhausting backends with bounded connection pools. This issue is fixed in 2.11.56 and 3.7.12.

Traefik is an open source HTTP reverse proxy and load balancer. Prior to 2.11.56, and from 3.0.0 until 3.7.12, a client-supplied dot-form header such as X.Authenticated.User survives ForwardAuth replacement and underscoreHeadersStrategy because Go treats it as distinct from X-Authenticated-User while normalization-prone CGI, WSGI, PHP, and NGINX backends collapse both names. A backend can consequently consume the client value instead of the identity Traefik asserted, allowing identity spoofing for any header managed by Traefik. The aliasHeadersStrategy protection is disabled by default and must be configured as delete or reject. The mitigation is available in 2.11.56 and 3.7.12.

Traefik is an open source HTTP reverse proxy and load balancer. Prior to 2.11.57, and 3.7.13, Traefik accepts a rootless HTTP/1 request target that Go stores in URL.Opaque while leaving URL.Path empty. The rewriteRequestBuilder path evaluates routing, path sanitization, forwardAuth, encodedCharacters, and access logging against a path normalized to / but forwards URL.Opaque verbatim to the backend, allowing cross-vhost routing bypass, path-scoped authorization bypass, and access-log evasion when the backend interprets the opaque target as a path. This issue is fixed in 2.11.57 and 3.7.13.

Traefik is an open source HTTP reverse proxy and load balancer. From 3.2.0 until 3.7.13, Traefik entrypoint defenses aliasHeadersStrategy, underscoreHeadersStrategy, and forwardedHeaders inspect req.Header but not req.Trailer, allowing an unauthenticated client to submit an aliasing or trusted header name in an HTTP/1.1 chunked trailer or an HTTP/2 trailer. When the retry or buffering middleware reads the body before the reverse proxy clones the request, the attacker-controlled trailer value reaches a backend that merges trailers into the header namespace, bypassing the documented delete or reject behavior and potentially spoofing identity or forwarded routing data. This issue is fixed in 3.7.13.

Traefik v1.x, v2.x through v2.11.55, and v3.0.0 through v3.7.11 canonicalize header names only on dashes, so X-Auth-User, X_Auth_User, and X.Auth.User are treated as three distinct headers by Traefik, while backends that derive variable names from header names (CGI, WSGI, PHP, NGINX, and others) collapse them into a single variable. A client can smuggle a dot-form alias of a header managed by Traefik alongside the canonical version, e.g., X.Authenticated.User alongside X-Authenticated-User, causing the backend to read the client-supplied value instead of the identity Traefik asserted.

Traefik versions >= v2.8.2 through <= v2.11.55 and >= v3.0.0 through <= v3.7.11 do not apply the entryPoints.<name>.transport.respondingTimeouts settings (notably readTimeout, enabled by default at 60s) to the HTTP/3 request path. readTimeout is enforced as a deadline on the underlying TCP connection, which cannot be applied to a QUIC stream, and Traefik's HTTP/3 server is constructed without any timeout. As a result, an unauthenticated remote client can trickle request body bytes and hold a request open indefinitely.

Vulnerability in Traefik (versions 3.0.0 to 3.6.25 and 3.7.10) in the Kubernetes Gateway API provider. Router and service identity construction can cause collisions, allowing overwriting another namespace's backend.

Traefik from 3.6.11 to 3.6.25 and 3.7.10 has a vulnerability in BasicAuth middleware allowing an attacker with valid credentials and hash to authenticate as an unconfigured username.

In Traefik before versions 2.11.54, 3.6.25, and 3.7.10, cross-namespace @kubernetescrd references are not rejected for TraefikService backend references resolved by the service resolver. A tenant confined by RBAC to a single namespace can bind its own router to a TraefikService owned by another namespace and expose or reroute that namespace's backend, defeating the namespace isolation allowCrossNamespace=false is meant to enforce.

Traefik versions >= v3.7.0 and <= v3.7.7 contain a path traversal vulnerability in the Kubernetes Ingress NGINX provider's RewriteTarget middleware (generated from the nginx.ingress.kubernetes.io/rewrite-target annotation). When an Ingress path uses a regex that captures attacker-controlled text without requiring a path separator (e.g., path /api(.*) with rewrite target /$1), a crafted request such as /api../admin matches the public router, is rewritten to a dot-segment traversal path (/../admin), and is forwarded without post-replacement normalization validation. A backend that normalizes dot segments resolves the path to a protected endpoint (e.g., /admin) reachable only through a separate router secured with BasicAuth, DigestAuth, or ForwardAuth, resulting in route-level authentication bypass. The issue is fixed in v3.7.8.

Traefik 3.6.0-3.6.22 and 3.7.0-3.7.6 fail to enforce the crossProviderNamespaces allowlist for IngressRouteTCP service serversTransport references. A low-privileged Kubernetes user in an unauthorized namespace can set serversTransport: foo@file, allowing use of file-provider TCPServersTransport, including privileged mTLS client certificates, SPIFFE identity, or PROXY-protocol settings. Fixed in 3.6.23 and 3.7.7.

Traefik versions 3.7.0 through 3.7.6 contain a namespace confusion vulnerability in the Kubernetes Gateway API provider. When resolving HTTPRoute.spec.rules[].backendRefs[].filters[].extensionRef, Traefik used the backend Service namespace instead of the HTTPRoute namespace. A low-privileged route author holding a ReferenceGrant for a cross-namespace Service could therefore bind a Traefik Middleware from the backend namespace without a separate grant for that middleware, potentially injecting trusted reverse-proxy identity headers into downstream requests. The issue is fixed in version 3.7.7.

Traefik versions up to 2.11.51, from 3.6.0 to 3.6.22, and from 3.7.0 to 3.7.6 contain an authentication bypass via path traversal in the ReplacePathRegex middleware. An unauthenticated attacker can send a crafted request that, after processing by the middleware, reaches the backend without path normalization validation, allowing access to protected resources.

Traefik versions 3.7.0 through 3.7.5 have a vulnerability in the Kubernetes Gateway API provider where two accepted HTTPRoutes targeting the same backend Service:port but with different backendRef filters may apply only one route's filter set to all requests reaching that backend. An attacker can impose their filter context on another route's requests, potentially crossing namespace boundaries.

In Traefik prior to versions v2.11.51, v3.6.22, and v3.7.6, the ForwardAuth middleware, even when configured with trustForwardHeader: false, derives the X-Forwarded-Port header from the original incoming request instead of the sanitized forwarded request. An unauthenticated remote attacker can inject an X-Forwarded-Proto: https header over a plain HTTP connection and cause Traefik to forward X-Forwarded-Port: 443 to the authentication service, bypassing port-based authorization checks.

A vulnerability in Traefik before 2.10.5 and 3.0.0-beta4 allows DoS via rapid creation and cancellation of HTTP/2 streams (Rapid Reset technique). The issue originates from the Go standard library's HTTP/2 implementation.

In Traefik versions prior to 2.11.43, 3.6.14, and 3.7.0-rc.2, a high severity authentication bypass vulnerability exists in the StripPrefixRegex middleware when used with ForwardAuth, BasicAuth, or DigestAuth. The issue arises from a mismatch between the decoded URL path and the raw path after stripping, allowing a request with a dot-segment (e.g., /./admin/secret) to reach the backend, which normalizes it to the protected path.

In Traefik prior to versions 2.11.42, 3.6.11, and 3.7.0-ea.3, when `headerField` is configured with a non-canonical HTTP header name (e.g., `x-auth-user` instead of `X-Auth-User`), an authenticated attacker can inject their own canonical version of that header to impersonate any identity to the backend. The backend receives two header entries, with the attacker-injected canonical one being read first, overriding Traefik's non-canonical write.

A vulnerability in Traefik allows injection of routing rules by interpolating unsanitized user input in the Knative provider. Attackers can bypass host restrictions and route traffic to attacker-controlled domains, leading to unauthorized access to victim services in multi-tenant clusters.

A vulnerability in Traefik allows bypassing mutual TLS (mTLS) authentication by sending a fragmented ClientHello packet. When SNI extraction fails due to fragmentation, the TCP router falls back to the default TLS configuration, which does not require client certificates.

In Traefik versions 2.11.9 to 2.11.37 and 3.1.3 to 3.6.8, there is a vulnerability due to incorrect case sensitivity handling in the Connection header. A remote unauthenticated attacker can use lowercase Connection tokens to bypass protection and remove Traefik-managed X-Forwarded headers.

In Traefik prior to versions 2.11.38 and 3.6.9, a vulnerability exists in TLS handshake management on TCP routers. An unauthenticated attacker can send an incomplete TLS record and stop transmission, causing the handshake to stall indefinitely and holding connections open.

A vulnerability in Traefik before version 3.6.8 allows an unauthenticated client to bypass the readTimeout by sending an 8-byte Postgres SSLRequest (STARTTLS) prelude and then stalling, causing connections to remain open indefinitely and leading to a denial of service.