The essentials
- On 16 October 2026, CERT-FR issued CERTFR-2026-AVI-1330 for two Traefik vulnerabilities in releases before v3.7.15, with risks to data confidentiality and security-policy bypass.
- GHSA-p8wx-ph99-xgcr (High, CVSS 7.0): with the Kubernetes Ingress NGINX provider, mutual TLS via the auth-tls-secret annotation can be silently disabled when another Ingress on the same host lacks matching auth-tls settings.
- GHSA-28hp-c82p-8vqj (Low): with allowCrossNamespaceResources disabled, a TLS-option cache can reuse another namespace’s CA secret without re-running the cross-namespace authorization check (since v3.7.11).
- Traefik v2 is unaffected (no Ingress NGINX provider); the vendor fix is v3.7.15.
What CERT-FR reports
On 16 October 2026, CERT-FR published advisory CERTFR-2026-AVI-1330 for multiple vulnerabilities in Traefik. The official summary states an attacker could cause loss of data confidentiality and security-policy bypass. Versions before v3.7.15 are affected. The notice references two GitHub Security Advisories released the same day by the vendor.
Mutual TLS quietly dropped on a shared host
GHSA-p8wx-ph99-xgcr (High, 7.0 CVSS v4) affects Traefik’s Kubernetes Ingress NGINX provider (≥ v3.7.0-ea.1 through v3.7.14). When an Ingress enables client TLS authentication with `nginx.ingress.kubernetes.io/auth-tls-secret`, that protection can be silently removed if another Ingress defines a path on the same host without matching auth-tls settings. Traefik binds client-auth TLS options per Ingress rather than per host; conflicting TLS options on the host make Traefik fall back to default TLS options, which do not request a client certificate, unless `core.strictTLSOptions` is enabled. A remote attacker without privileges could reach backends that were meant to require a client certificate.
Cross-namespace isolation and TLS caching
GHSA-28hp-c82p-8vqj (Low, 2.1) applies to ≥ v3.7.11 through v3.7.14. With `allowCrossNamespaceResources` disabled (the default), the cross-namespace check on auth-tls-secret runs only when a client-auth TLS option is first built: a later Ingress referencing a CA secret already used by another Ingress reuses the shared TLS option without being re-checked. A user allowed to create Ingresses in one namespace can therefore have a CA secret from another namespace enforced on their routes, bypassing configured isolation, and learn whether that secret exists — without reading its contents. This stems from sharing client-auth TLS options across Ingresses, introduced in v3.7.11.
- Scope: clusters running Traefik v3.7.x with the Ingress NGINX provider (nginx annotation compatibility or ingress-nginx migration).
- Fix: upgrade Traefik to v3.7.15 (vendor release of 16 October 2026).
- Interim mitigation (High flaw): enable `core.strictTLSOptions` if you cannot patch immediately — the vendor advisory cites it to avoid falling back to permissive TLS options.
- Ingress review: do not mix routes with and without auth-tls-secret on the same host; document who may create Ingresses per namespace.
- Traefik v2: not affected (provider absent); Traefik v3 before v3.7.0: auth-tls-secret support did not exist yet.
Sources
- Multiples vulnérabilités dans TraefikANSSI — CERT-FR · 16 October 2026
- ingress-nginx provider: mTLS silently disabled (GHSA-p8wx-ph99-xgcr)Traefik — GitHub Security Advisories · 16 October 2026
- Kubernetes Ingress NGINX provider: TLS-option cache skips cross-namespace check (GHSA-28hp-c82p-8vqj)Traefik — GitHub Security Advisories · 16 October 2026
- Traefik v3.7.15Traefik · 16 October 2026
This note was drafted with AI tools from the cited sources, then reviewed and published under the responsibility of Jordan FOUASSIER, publication director. We summarise the facts and add our reading; source text and images are not reproduced. An error? Write to contact@aigyrosgroup.com.