CVE-2026-114636 in Traefik
Summary
by MITRE • 10/22/2026
Traefik v3.7.13 before v3.7.14 contains an access-control bypass in the Kubernetes Ingress NGINX provider, where the HTTP router generated for ssl-passthrough Ingresses on non-TLS entry points never applies the Ingress's access-control annotations. Unauthenticated attackers reaching the HTTP entry point with the Ingress host can access backends protected by auth-type, auth-url, or whitelist-source-range annotations, with nothing logged.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Traefik versions prior to 3.7.14 represents a critical failure in access control enforcement within the Kubernetes Ingress NGINX provider. This flaw specifically affects configurations involving SSL passthrough ingress resources that are exposed via non-TLS entry points, such as standard HTTP listeners on port 80. Under normal operational expectations, Traefik should enforce security policies defined by annotations like auth-type, auth-url, or whitelist-source-range regardless of the transport layer protocol used to reach the service. However, due to a logic error in how routers are generated for these specific ingress types, the access control middleware is entirely omitted from the HTTP router configuration when SSL passthrough is enabled and the entry point does not utilize TLS encryption. This creates a significant gap where security controls that should be universally applied are effectively disabled by default for this subset of traffic flows.
From a technical perspective, the root cause lies in the conditional logic used during the routing table generation phase. When Traefik processes an Ingress resource with SSL passthrough enabled, it typically delegates TLS termination to the backend service or assumes that all security checks occur at the transport layer. However, when this ingress is mapped to a non-TLS entry point, the provider fails to attach the necessary middleware chain defined by the access-control annotations. Consequently, any HTTP request directed at the host specified in the Ingress resource bypasses authentication and authorization mechanisms entirely. The traffic flows directly from the listener to the backend service without inspection or restriction, effectively rendering the configured security policies inert for this specific configuration scenario.
The operational impact of this vulnerability is severe, as it allows unauthenticated attackers to access sensitive backends that are intended to be protected. An attacker who can reach the HTTP entry point and knows the host name associated with the vulnerable ingress resource can interact directly with the backend application services. This bypasses both authentication mechanisms, such as basic auth or external OAuth providers configured via auth-url, and network-based restrictions like IP whitelisting defined in whitelist-source-range annotations. Furthermore, because the request is processed by Traefik without triggering security middleware events, these unauthorized access attempts are not logged. The absence of audit trails makes detection difficult and hinders incident response efforts, as administrators may remain unaware that their protected services have been compromised until actual data exfiltration or system manipulation occurs.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting a failure to enforce access control in web applications where security policies are inconsistently applied based on configuration parameters. It also maps to MITRE ATT&CK technique T1078 Valid Accounts if the backend requires authentication that is bypassed, or more broadly to unauthorized access patterns associated with misconfigured identity and access management controls. The lack of logging further exacerbates the risk by violating principles of accountability and auditability found in standards such as NIST SP 800-53 AC-9 Audit Actions, which mandates monitoring for security-relevant events.
To mitigate this vulnerability, organizations running Traefik versions prior to 3.7.14 must upgrade immediately to version 3.7.14 or later where the logic error in router generation has been corrected. Until an upgrade is feasible, administrators should avoid exposing SSL passthrough ingress resources via non-TLS entry points. Instead, all traffic intended for these services should be routed through TLS-enabled entry points on port 443 to ensure that standard security middleware chains are applied correctly. Additionally, implementing network-level segmentation or firewall rules can provide a compensating control by restricting direct HTTP access to the Traefik nodes from untrusted networks, thereby reducing the attack surface available for exploitation of this misconfiguration.