Impact
There is a potential vulnerability in Traefik managing the requests using a PathPrefix, Path or PathRegex matcher.
When Traefik is configured to route the requests to a backend using a matcher based on the path, if the URL contains a /../ in its path, it’s possible to target a backend, exposed using another router, by-passing the middlewares chain.
Example
yaml apiVersion: traefik.io/v1alpha1 kind: IngressRoute metadata: name: my-service spec: routes: - match: PathPrefix(‘/service’) kind: Rule services: - name: service-a port: 8080 middlewares: - name: my-middleware-a - match: PathPrefix(‘/service/sub-path’) kind: Rule services: - name: service-a port: 8080
In such a case, the request http://mydomain.example.com/service/sub-path/../other-path will reach the backend my-service-a without operating the middleware my-middleware-a unless the computed path is http://mydomain.example.com/service/other-path and should be computes by the first router (operating my-middleware-a).
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.24 - https://github.com/traefik/traefik/releases/tag/v3.3.6 - https://github.com/traefik/traefik/releases/tag/v3.4.0-rc2
Workaround
Add a PathRegexp rule to the matcher to prevent matching a route with a /../ in the path.
Example:
yaml match: PathPrefix(/service) && !PathRegexp((?:(/\.\./)+.))
For more information
If you have any questions or comments about this advisory, please open an issue.
Traefik is an open source HTTP reverse proxy and load balancer. In affected versions there is a potential vulnerability in Traefik managing TLS connections. A router configured with a not well-formatted TLSOption is exposed with an empty TLSOption. For instance, a route secured using an mTLS connection set with a wrong CA file is exposed without verifying the client certificates. Users are advised to upgrade to version 2.9.6. Users unable to upgrade should check their logs to detect the error messages and fix your TLS options.
Impact
There is a potential vulnerability in Traefik ACME TLS certificates' automatic generation: the ACME TLS-ALPN fast path can allow unauthenticated clients to tie up goroutines and file descriptors indefinitely when the ACME TLS challenge is enabled.
A malicious client can open many connections, send a minimal ClientHello with acme-tls/1, then stop responding, leading to denial of service of the entrypoint.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.35 - https://github.com/traefik/traefik/releases/tag/v3.6.7
For more information
If you have any questions or comments about this advisory, please open an issue.
<details> <summary>Original Description</summary>
\[Security\] ACME TLS-ALPN fast path lacks timeouts and close on handshake stall
Dear Traefik security team,
We believe we have identified a resource-exhaustion issue in the ACME TLS-ALPN fast path that can allow unauthenticated clients to tie up goroutines and file descriptors indefinitely when the ACME TLS challenge is enabled.
Summary
- Affected code: pkg/server/router/tcp/router.go (ACME TLS-ALPN handling). - When a ClientHello advertises acme-tls/1, Traefik intercepts it and calls tls.Server(...).Handshake() without any read/write deadlines and without closing the connection afterward. - Immediately before this branch, existing deadlines set by the entrypoint are cleared. - A client that sends the ALPN marker and then stops responding can keep the goroutine and socket open indefinitely, potentially exhausting the entrypoint under load. - Exposure is limited to entrypoints where the ACME TLS-ALPN challenge is enabled and ACME bypass is not allowed.
Relevant snippets 143:171:pkg/server/router/tcp/router.go // Deadlines are cleared before protocol dispatch if err := conn.SetDeadline(time.Time{}); err != nil { log.Error().Err(err).Msg("Error while setting deadline") }
// ACME TLS-ALPN fast path if !r.acmeTLSPassthrough && slices.Contains(hello.protos, tlsalpn01.ACMETLS1Protocol) { r.acmeTLSALPNHandler().ServeTCP(r.GetConn(conn, hello.peeked)) return }
224:226:pkg/server/router/tcp/router.go // Handler invoked by the branch above return tcp.HandlerFunc(func(conn tcp.WriteCloser) { = tls.Server(conn, r.httpsTLSConfig).Handshake() })
Impact
- Each stalled handshake consumes a goroutine and FD with no timeout and no server-side close. - A malicious client can open many connections, send a minimal ClientHello with acme-tls/1, then stop responding, leading to denial of service of the entrypoint. - Normal HTTPS handling uses http.Server timeouts; this bespoke path bypasses them.
Conditions for exploitation
- ACME TLS-ALPN challenge enabled (default when configured). - allowACMEByPass disabled for the entrypoint (the default when ACME TLS challenge is handled by Traefik).
CWE
- CWE-400: Uncontrolled Resource Consumption.
Proposed fix (illustrative)
@@ func (r Router) acmeTLSALPNHandler() tcp.Handler { - return tcp.HandlerFunc(func(conn tcp.WriteCloser) { - = tls.Server(conn, r.httpsTLSConfig).Handshake() - }) + return tcp.HandlerFunc(func(conn tcp.WriteCloser) { + // Ensure the handshake cannot block indefinitely and always closes the socket. + = conn.SetReadDeadline(time.Now().Add(10 time.Second)) + = conn.SetWriteDeadline(time.Now().Add(10 time.Second)) + + tlsConn := tls.Server(conn, r.httpsTLSConfig) + = tlsConn.Handshake() + = tlsConn.Close() // close regardless of handshake outcome + }) }
Alternatively, route ACME TLS-ALPN through the existing tcp.TLSHandler/HTTP server path so the configured timeouts and lifecycle management apply automatically.
CVSS v3.1 (estimate)
- Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Base score: 7.5 (High) - Rationale: Network-only, no auth/user interaction required; impact is service availability via resource exhaustion; no confidentiality or integrity impact.
Please let us know if you would like a PoC or further details. We have not made any code changes in this report.
Let us know if you have any questions or need clarification\!
Best wishes, Pavel Kohout Aisle Research </details>
Traefik is an HTTP reverse proxy and load balancer. Prior to version 2.6.1, Traefik skips the router transport layer security (TLS) configuration when the host header is a fully qualified domain name (FQDN). For a request, the TLS configuration choice can be different than the router choice, which implies the use of a wrong TLS configuration. When sending a request using FQDN handled by a router configured with a dedicated TLS configuration, the TLS configuration falls back to the default configuration that might not correspond to the configured one. If the CNAME flattening is enabled, the selected TLS configuration is the SNI one and the routing uses the CNAME value, so this can skip the expected TLS configuration. Version 2.6.1 contains a patch for this issue. As a workaround, one may add the FDQN to the host rule. However, there is no workaround if the CNAME flattening is enabled.
Traefik 2.x, in certain configurations, allows HTTPS sessions to proceed without mutual TLS verification in a situation where ERRBADSSLCLIENTAUTHCERT should have occurred.
Containous Traefik 1.6.x before 1.6.6, when --api is used, exposes the configuration and secret if authentication is missing and the API's port is publicly reachable.
Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that assists in deploying microservices. There is a potential vulnerability in Traefik managing HTTP/2 connections. A closing HTTP/2 server connection could hang forever because of a subsequent fatal error. This failure mode could be exploited to cause a denial of service. There has been a patch released in versions 2.8.8 and 2.9.0-rc5. There are currently no known workarounds.
Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer for deploying microservices. There is a vulnerability in Go when parsing the HTTP headers, which impacts Traefik. HTTP header parsing could allocate substantially more memory than required to hold the parsed headers. This behavior could be exploited to cause a denial of service. This issue has been patched in versions 2.9.10 and 2.10.0-rc2.
types/types.go in Containous Traefik 1.7.x through 1.7.11, when the --api flag is used and the API is publicly reachable and exposed without sufficient access control (which is contrary to the API documentation), allows remote authenticated users to discover password hashes by reading the Basic HTTP Authentication or Digest HTTP Authentication section, or discover a key by reading the ClientTLS section. These can be found in the JSON response to a /api request.
Summary
The traefik docker container uses 100% CPU when it serves as its own backend, which is an automatically generated route resulting from the Docker integration in the default configuration.
Details
While attempting to set up Traefik to handle traffic for Docker containers, I observed in the webUI a rule with the following information:
Host(traefik-service) | webwebsecure | traefik-service@docker | traefik-service
I assumed that this is something internal; however, I wondered why it would have a host rule on the web entrypoint configured.
So I have send a request with that hostname with curl -v --resolve "traefik-service:80:xxx.xxx.xxx.xxx" http://traefik-service. That made my whole server unresponsive.
I assume the name comes from a docker container with that name, traefik itself: localhost ~ # docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d1414e74aec7 traefik:v2.10 "/entrypoint.sh trae…" 4 minutes ago Up 4 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp, 127.0.0.1:8080->8080/tcp traefik.service
PoC
1. Start traefik with docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -p 80:80 --name foo -p 8080:8080 traefik:v2.10 --api.insecure=true --providers.docker
2. curl -v --resolve "foo:80:127.0.0.1" http://foo
looks like this creates an endless loop of request.
Knowing the name of the docker container seems to be enough to trigger this, if the docker backend is used.
Impact
Server is unreachable and uses 100% CPU
Traefik is an open source HTTP reverse proxy and load balancer. Versions prior to 2.9.6 are subject to a potential vulnerability in Traefik displaying the Authorization header in its debug logs. In certain cases, if the log level is set to DEBUG, credentials provided using the Authorization header are displayed in the debug logs. Attackers must have access to a users logging system in order for credentials to be stolen. This issue has been addressed in version 2.9.6. Users are advised to upgrade. Users unable to upgrade may set the log level to INFO, WARN, or ERROR.
Summary When a request is sent to Traefik with a URL fragment, Traefik automatically URL encodes and forwards the fragment to the backend server. This violates the RFC because in the origin-form the URL should only contain the absolute path and the query.
When this is combined with another frontend proxy like Nginx, it can be used to bypass frontend proxy URI-based access control restrictions.
Details For example, we have this Nginx configuration:
location /admin { deny all; return 403; } This can be bypassed when the attacker is requesting to /#/../admin
This won’t be vulnerable if the backend server follows the RFC and ignores any characters after the fragment.
However, if Nginx is chained with another reverse proxy which automatically URL encode the character # (Traefik) the URL will become
/%23/../admin
And allow the attacker to completely bypass the Access Restriction from the Nginx Front-End proxy.
Here is a diagram to summarize the attack:
!image
PoC !image (1)
This is the POC docker I've set up. It contains Nginx, Traefik proxies and a backend server running PHP.
https://drive.google.com/file/d/1vLnA0g7N7ZKhLNmHmuJ4JJjVJ2akNMt/view?usp=sharing
Impact This allows the attacker to completely bypass the Access Restriction from Front-End proxy.
In Traefik before versions 1.7.26, 2.2.8, and 2.3.0-rc3, there exists a potential open redirect vulnerability in Traefik's handling of the "X-Forwarded-Prefix" header. The Traefik API dashboard component doesn't validate that the value of the header "X-Forwarded-Prefix" is a site relative path and will redirect to any header provided URI. Successful exploitation of an open redirect can be used to entice victims to disclose sensitive information. Active Exploitation of this issue is unlikely as it would require active header injection, however the Traefik team addressed this issue nonetheless to prevent abuse in e.g. cache poisoning scenarios.
Impact
There is a potential vulnerability in Traefik managing the ACME HTTP challenge.
When Traefik is configured to use the HTTPChallenge to generate and renew the Let's Encrypt TLS certificates, the delay authorized to solve the challenge (50 seconds) can be exploited by attackers (slowloris attack). Patches
- https://github.com/traefik/traefik/releases/tag/v2.10.6 - https://github.com/traefik/traefik/releases/tag/v3.0.0-beta5
Workarounds
Replace the HTTPChallenge with the TLSChallenge or the DNSChallenge.
For more information
If you have any questions or comments about this advisory, please open an issue.
End of life: 12/11/2019, End of support: 12/11/2019, Latest version: 2.0.7
End of life: 12/11/2019, End of support: 12/11/2019, Latest version: 2.0.7
End of life: 3/25/2020, End of support: 3/25/2020, Latest version: 2.1.9
End of life: 3/25/2020, End of support: 3/25/2020, Latest version: 2.1.9
End of life: 1/19/2021, End of support: 1/19/2021, Latest version: 2.3.7
End of life: 1/19/2021, End of support: 1/19/2021, Latest version: 2.3.7
End of life: 6/29/2022, End of support: 6/29/2022, Latest version: 2.7.3
End of life: 6/29/2022, End of support: 6/29/2022, Latest version: 2.7.3
End of life: 5/24/2022, End of support: 5/24/2022, Latest version: 2.6.7
End of life: 5/24/2022, End of support: 5/24/2022, Latest version: 2.6.7
End of life: 2/12/2024, End of support: 2/12/2024, Latest version: 2.10.7
End of life: 2/12/2024, End of support: 2/12/2024, Latest version: 2.10.7
End of life: 10/3/2022, End of support: 10/3/2022, Latest version: 2.8.8
End of life: 10/3/2022, End of support: 10/3/2022, Latest version: 2.8.8
End of life: 1/24/2022, End of support: 1/24/2022, Latest version: 2.5.7
End of life: 1/24/2022, End of support: 1/24/2022, Latest version: 2.5.7