High priorityDisclosed

Advisory · CVE-2026-114640

Traefik Ingress NGINX HTTP router forwards forged Ssl-Client identity headers to backends

Traefik from 3.7.0 before 3.7.14 forwards client-supplied Ssl-Client headers on the plaintext HTTP router for Ingresses using auth-tls-pass-certificate-to-upstream, so when ssl-redirect is disabled an unauthenticated attacker can impersonate any mutual TLS identity a backend trusts from those headers. CVSS 3.1 8.7.

Advisory published October 22, 2026Independent summary
Vendor
Traefik
Product
Traefik
Identifier / CWE
CVE-2026-114640
CWE-290
Action timing
Immediate
ELI5

Explain it like I’m five

The backend believes a stamped form that says this visitor showed a certificate. On the plain HTTP route nobody stamps or checks the form, so visitors can fill in any name they like and be believed.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Attacker crafts identity headers

    An unauthenticated client prepares a plaintext HTTP request carrying Ssl-Client-Verify SUCCESS with a chosen certificate subject and issuer.

  2. 02HTTP router forwards them as sent

    Per Traefik, the middleware that owns those headers is attached only to the TLS router, so the HTTP router generated for the same Ingress forwards them exactly as the client sent them.

  3. 03Redirect-off route reaches the backend

    When ssl-redirect is set to false, that HTTP router reaches the backend instead of only issuing a redirect.

  4. 04Backend trusts the forged identity

    A backend that trusts those proxy-generated fields as a mutual TLS identity authorizes the request even though no client certificate was presented.

What happened

Traefik disclosed CVE-2026-114640 in its GitHub security advisory: in the Kubernetes Ingress NGINX provider, for an Ingress carrying the auth-tls-pass-certificate-to-upstream annotation, the middleware that owns the Ssl-Client request headers is attached only to the TLS router, so the plaintext HTTP router generated for the same Ingress forwards those headers exactly as the client sent them. Traefik states that when ssl-redirect is set to false that router reaches the backend, and an unauthenticated client can supply Ssl-Client-Verify SUCCESS together with a chosen certificate subject and issuer, so a backend that trusts those fields as a mutual TLS identity authorizes the request even though no client certificate was presented. The CVSS 3.1 score is 8.7, with changed scope.

Per Traefik, only the v3.7 line is affected: support for the auth-tls-pass-certificate-to-upstream annotation was added in v3.7.0, and earlier versions do not translate it. The fix is v3.7.14. No fixed version is claimed here for other lines, because Traefik does not list one.

What to do

  1. Inventory Traefik deployments from 3.7.0 before 3.7.14 using the Kubernetes Ingress NGINX provider, and list Ingresses that combine auth-tls-pass-certificate-to-upstream with ssl-redirect set to false.
  2. Upgrade affected deployments to Traefik 3.7.14.
  3. Until upgraded, re-enable ssl-redirect on those Ingresses or block their plaintext HTTP entry point, and make backends reject Ssl-Client headers that arrive on non-TLS routes.
  4. Hunt for backend authorizations based on Ssl-Client headers where the request arrived over HTTP or without a client certificate, and for identities that never held the claimed certificate.
  5. Verify the deployed version and retest header handling on both routers after updating.

Management note

Header-based identity is only as strong as the proxy stripping those headers on every route. One unstripped HTTP route turned it into self-asserted identity, so upgrade and check every backend that trusts Ssl-Client fields.