High priorityDisclosed

Advisory · CVE-2026-114638

Traefik Ingress NGINX client CA mix-up lets one host accept certificates from another host CA

Traefik from 3.7.0 before 3.7.14 merges client CAs in its Kubernetes Ingress NGINX provider when auth-tls-secret names collide after dot-to-dash normalization, so a host requiring its own client CA can accept certificates from another host CA while its legitimate clients are refused. CVSS 3.1 8.7.

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

Explain it like I’m five

Two different key cabinets got the same label because a dot and a dash were treated as the same character, so one site started trusting the other site keys and rejecting its own.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Two secrets have colliding names

    Two auth-tls-secret references differ only by a dot versus a dash, such as my.secret and my-secret, in the Ingress NGINX provider.

  2. 02Names normalize to the same TLS option

    Per Traefik, the generated TLS option name replaces every dot with a dash, so both secrets produce the same option name.

  3. 03Second Ingress reuses the first option

    The Ingress processed second silently reuses the TLS option built for the first one.

  4. 04Wrong CA gates the host

    A host configured to require client certificates from its own CA is gated by the other host CA: those certificates are accepted, while the host legitimate clients are refused.

What happened

Traefik disclosed CVE-2026-114638 in its GitHub security advisory: in the Kubernetes Ingress NGINX provider, the TLS option generated for an Ingress carrying the auth-tls-secret annotation is named from the referenced Secret namespace and name after normalizing them, which replaces every dot with a dash. Traefik states that two Secrets whose names differ only by a dot and a dash therefore produce the same TLS option name, and the Ingress processed second silently reuses the option built for the first one, so a host configured to require client certificates issued by its own CA is then gated by another host CA. In v3.7.0 to v3.7.10, where the generated name also included the Ingress name, the same collision could occur between Ingresses whose names normalize identically. The CVSS 3.1 score is 8.7, with changed scope.

Per Traefik, the auth-tls-secret annotation is supported by the Ingress NGINX provider since v3.7.0, so Traefik v2 and v3 versions before v3.7.0 are not affected, and the fix is v3.7.14. Traefik states the provider now keeps the resource names as is in the names it generates.

What to do

  1. Inventory Traefik deployments from 3.7.0 before 3.7.14 using the Kubernetes Ingress NGINX provider, and list Ingresses using the auth-tls-secret annotation.
  2. Check for secret or Ingress names that differ only by dots versus dashes across hosts that use different client CAs; those are the collision candidates.
  3. Upgrade affected deployments to Traefik 3.7.14.
  4. Until upgraded, rename colliding secrets so no two normalize to the same name, and re-check which CA each affected host actually presents as required.
  5. Hunt for client certificate logins on a host using certificates issued by a different host CA, and for legitimate clients being refused.
  6. Verify the deployed version and test client certificate access per host after updating.

Management note

Mutual TLS only protects a host if the right CA gates it. A naming collision quietly swapped that gate between hosts, so audit the collisions, not just the version, and upgrade to 3.7.14.