High priorityDisclosed

Advisory · CVE-2026-114636

Traefik ssl-passthrough Ingresses get an HTTP router that ignores their auth annotations

Traefik 3.7.13, fixed in 3.7.14, builds an extra HTTP router for ssl-passthrough Ingresses in the Kubernetes Ingress NGINX provider without applying the Ingress auth and allow-list annotations, so unauthenticated clients on the HTTP entry point can reach protected backends with nothing logged. CVSS 3.1 8.7.

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

Explain it like I’m five

The operator locked the front door with auth annotations, but Traefik quietly built a second, unlocked side door on the plain HTTP port for the same backend, and did not even log who used it.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Operator protects an Ingress

    An Ingress carries the ssl-passthrough annotation together with access-control annotations such as auth-type, auth-url or a source allow-list.

  2. 02Sibling HTTP router is built

    Per Traefik, the Ingress also gets an HTTP router on the non-TLS entry points, built outside the regular per-rule processing.

  3. 03Annotations are never applied

    The access-control annotations were parsed but never turned into middlewares on that HTTP router.

  4. 04Unauthenticated access succeeds

    An unauthenticated client reaching the HTTP entry point with the Ingress host reaches the protected backend with no authentication, no allow-listing and nothing logged.

What happened

Traefik disclosed CVE-2026-114636 in its GitHub security advisory: in the Kubernetes Ingress NGINX provider, since v3.7.13 an Ingress carrying the ssl-passthrough annotation gets, besides its TCP passthrough router, an HTTP router on the non-TLS entry points that proxies to the backend. Traefik states that router was built outside the regular per-rule processing, so the access-control annotations set on the same Ingress, such as auth-type with auth-secret, auth-url and whitelist-source-range, were parsed but never turned into middlewares on it. An unauthenticated client reaching the HTTP entry point with the Ingress host could therefore reach a backend the operator had annotated as protected, with no authentication and no source allow-listing applied, and nothing logged. The CVSS 3.1 score is 8.7, with changed scope.

Per Traefik, only v3.7.13 is affected in the maintained line: Traefik v2 and v3 versions before v3.7.13 are not affected, and the fix is v3.7.14. Traefik states the HTTP side of an ssl-passthrough Ingress is now built like any other Ingress with its annotation directives applied, and that the routers it generates are renamed as a result, pointing readers to the v3.7.14 migration guide.

What to do

  1. Inventory Traefik 3.7.13 deployments using the Kubernetes Ingress NGINX provider, and list Ingresses that combine ssl-passthrough with auth or allow-list annotations.
  2. Upgrade affected deployments to Traefik 3.7.14, and plan for the router renaming Traefik describes in the v3.7.14 migration guide.
  3. Until upgraded, consider blocking the non-TLS entry points for ssl-passthrough hosts at the load balancer or network layer, so the unprotected HTTP router cannot be reached.
  4. Hunt at the backend, not only in Traefik logs: Traefik states nothing was logged for this path, so look for requests arriving at protected backends without the expected authentication.
  5. Verify the deployed version on every Traefik instance and confirm the auth annotations are enforced on both TLS and HTTP routers after updating.

Management note

This is a silent bypass: the control looked applied in the Ingress definition and the access left no log line. If you migrated Ingresses with ssl-passthrough and auth annotations to Traefik 3.7.13, audit the backends directly and upgrade to 3.7.14.