CVE-2026-114638 in Traefik
Summary
by MITRE • 10/22/2026
Traefik v3.7.0 before v3.7.14 contains an improper authentication vulnerability in the Kubernetes Ingress NGINX provider that merges client CAs when auth-tls-secret names collide after dot-to-dash normalization. Attackers holding certificates from another host's CA can access a host requiring its own client CA, while that host's legitimate clients are refused.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Traefik versions prior to 3.7.14 represents a critical flaw within the Kubernetes Ingress NGINX provider, specifically concerning the handling of mutual Transport Layer Security authentication configurations. This issue arises from an improper implementation of certificate authority merging logic when processing client CA certificates defined via auth-tls-secret resources. The core technical defect lies in how Traefik normalizes secret names during configuration parsing. Specifically, the system performs a normalization step that converts dots to dashes in resource identifiers. When two distinct Kubernetes secrets with different underlying Certificate Authorities share names that become identical after this dot-to-dash transformation, the provider fails to maintain strict isolation between them. Instead of treating these as separate authentication contexts for their respective hosts or services, Traefik merges the client CA certificates from both sources into a single trust store associated with one of the conflicting entries.
This merging behavior creates a severe security boundary violation that undermines the integrity of mutual TLS authentication. In a typical multi-tenant Kubernetes environment, different namespaces or applications may rely on distinct internal Certificate Authorities to authenticate their respective clients. Due to this vulnerability, if an attacker controls or can create a secret with a name that collides after normalization with a legitimate service's auth-tls-secret, they can inject their own CA certificate into the trust store of the target host. Consequently, any client presenting a certificate signed by the attacker-controlled CA will be accepted as valid by the vulnerable Traefik instance. This effectively allows unauthorized entities to impersonate legitimate clients and gain access to protected backend services that should strictly reject such connections based on their specific organizational or application-level security policies.
The operational impact of this vulnerability is profound, particularly in environments where strict client authentication is enforced for sensitive APIs or internal microservices. Beyond the direct risk of unauthorized data access, the flaw introduces a denial-of-service vector against legitimate users. Because the merged trust store now includes both the attacker's CA and potentially other conflicting certificates, the validation logic may become ambiguous or fail to correctly distinguish between valid and invalid clients in complex scenarios. More critically, as noted in the vulnerability description, this misconfiguration can lead to situations where legitimate clients holding certificates from the correct, intended CA are refused access. This occurs because the authentication process might prioritize the merged list incorrectly or encounter validation errors due to conflicting certificate chains, effectively locking out authorized users while granting entry to unauthorized ones who possess certificates signed by the colliding attacker's CA.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-613 Insufficient Session Expiration, as it involves the failure of identity verification mechanisms due to flawed configuration handling. In terms of the MITRE ATT&CK framework, this flaw facilitates Initial Access through Tactic TA0001 by allowing attackers to bypass authentication controls using forged credentials derived from a compromised or maliciously created Certificate Authority. It also relates to Defense Evasion techniques where an attacker might exploit misconfigured trust relationships to operate undetected within the network perimeter. The root cause is not necessarily a code execution flaw but rather a logic error in resource name resolution and secret management, highlighting the importance of strict naming conventions and isolation policies when configuring ingress controllers that handle sensitive cryptographic materials.
Mitigation for this vulnerability requires immediate upgrading to Traefik version 3.7.14 or later, where the issue with dot-to-dash normalization collision has been resolved. In addition to patching, administrators should audit their Kubernetes clusters for any auth-tls-secret resources whose names might collide after character substitution. Implementing strict naming conventions that avoid ambiguous characters like dots in secret names used for TLS authentication can prevent such collisions proactively. Furthermore, organizations should enforce least-privilege access controls on the creation of secrets within namespaces to ensure that only authorized service accounts or administrators can define client CA certificates. Regular review of ingress configurations and validation of mutual TLS setups using independent testing tools is recommended to verify that certificate chains are correctly isolated per host or service as intended by the security architecture.