CVE-2026-119573 in Traefik
Summary
by MITRE • 10/30/2026
Traefik 3.7.11 before 3.7.15 contains an authorization bypass in the Kubernetes Ingress NGINX provider that skips the cross-namespace check on the auth-tls-secret annotation when a cached client authentication TLS option is reused. Users who can create Ingresses can reference another namespace's CA secret already used by another Ingress, enforcing it on their own routes and learning whether it exists, without disclosure of its contents.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Traefik versions prior to 3.7.15 represents a critical authorization bypass within the Kubernetes Ingress NGINX provider integration. This flaw specifically affects the handling of cross-namespace resource references when utilizing client authentication TLS secrets via the auth-tls-secret annotation. The core technical issue stems from an optimization mechanism where Traefik caches client authentication TLS options to improve performance and reduce redundant configuration operations. However, this caching logic fails to enforce strict namespace isolation boundaries during subsequent lookups or reuses of these cached configurations. When a user creates an Ingress resource in their own namespace and references a CA secret located in a different namespace that has already been utilized by another existing Ingress, the system incorrectly assumes the cached TLS option is valid for the new context without performing the necessary cross-namespace authorization checks. This oversight allows the attacker to effectively hijack or enforce the use of a remote namespace's certificate authority on their own routes.
From an operational impact perspective, this vulnerability enables several malicious outcomes that compromise both confidentiality and integrity within a multi-tenant Kubernetes cluster. First, it facilitates unauthorized access to resources protected by mutual TLS (mTLS) configurations defined in other namespaces. By forcing the use of another namespace's CA secret, an attacker can potentially bypass authentication mechanisms intended for their own namespace if those mechanisms rely on specific certificate validation logic tied to that external authority. Second, and perhaps more insidiously, this flaw allows for information disclosure through existence proofs. Even though the actual private keys or sensitive contents of the referenced secrets are not exposed, the ability to successfully enforce a reference to another namespace's secret confirms its presence in the cluster. This enumeration capability aids attackers in mapping out the internal architecture of the Kubernetes environment, identifying which namespaces contain specific security configurations and potentially targeting other services that rely on similar trust relationships.
This vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to properly restrict access to resources based on namespace boundaries. Furthermore, it relates to CWE-798 Use of Hard-coded Credentials if the cached TLS options are treated as static trusted entities that bypass dynamic validation checks. In terms of the MITRE ATT&CK framework for Kubernetes, this behavior corresponds to T1530 Data from Cloud Storage Object and potentially T1652 Compromised Client Authentication Certificate, depending on how the attacker leverages the enforced CA secret to intercept or manipulate traffic. The attack vector is classified as Local Access with Low Privileges, requiring only the ability to create Ingress resources within a namespace, which is often granted to developers in standard CI/CD pipelines or team-based development environments without rigorous RBAC restrictions.
Mitigation strategies must focus on both immediate patching and long-term architectural hardening. The primary remediation is to upgrade Traefik to version 3.7.15 or later, where the cross-namespace check for auth-tls-secret annotations has been corrected to ensure that cached TLS options are not reused across namespace boundaries without explicit validation. In environments where immediate upgrading is not feasible, administrators should implement strict Role-Based Access Control (RBAC) policies within Kubernetes to prevent users from creating Ingress resources or referencing secrets in namespaces other than their own. Additionally, auditing existing RBAC roles for overly permissive access to ingressresources and secret objects can help limit the attack surface. It is also advisable to review network policies and service mesh configurations to ensure that mTLS enforcement does not rely solely on static CA references but includes dynamic validation of client certificates against expected identities within each specific namespace context.