CVE-2026-85597 in Traefik
Summary
by MITRE • 09/04/2026
Traefik before v2.11.55 contains a TLS option conflict resolution vulnerability that allows unauthenticated attackers to bypass client-certificate authentication by creating conflicting TLS options on multi-host routers. Attackers can reach protected backends by exploiting shared TLS resolution across multiple hostnames in a single router rule, causing the strict mTLS requirement to fall back to default options for all hosts.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in Traefik versions prior to 2.11.55 represents a critical flaw in how the reverse proxy handles Transport Layer Security configuration resolution across multi-host routing rules. This issue stems from an incorrect conflict resolution mechanism when multiple hostnames are defined within a single router entry that requires mutual TLS authentication. In such configurations, Traefik is expected to enforce strict client-certificate verification for each distinct hostname independently. However, the underlying logic fails to isolate these TLS contexts properly, leading to a shared state where configuration errors or conflicts in one part of the rule can inadvertently affect the security posture of other hosts within the same definition. This architectural oversight allows an unauthenticated attacker to manipulate the resolution process by introducing conflicting TLS options, thereby causing the system to abandon strict mutual authentication requirements and fall back to default, less secure settings for all associated hostnames.
From a technical perspective, this flaw is rooted in how Traefik processes dynamic configuration updates and resolves TLS provider conflicts. When a router rule encompasses multiple hosts, the proxy must maintain separate TLS contexts for each domain to ensure that certificate validation remains granular and specific to the intended service. The vulnerability arises because the conflict resolution algorithm does not adequately isolate these contexts. Instead, it applies a global fallback mechanism when inconsistencies are detected within the multi-host definition. Consequently, if an attacker can influence or exploit this inconsistency, whether through configuration manipulation in dynamic providers or by triggering edge cases during runtime updates, the strict mutual TLS requirement is overridden. The system defaults to standard TLS without client certificate verification, effectively stripping away the authentication layer that was intended to protect the backend services from unauthorized access.
The operational impact of this vulnerability is severe, as it directly compromises the integrity of identity-based security controls in environments relying on Traefik for ingress management and mutual TLS enforcement. Organizations utilizing mTLS to secure internal microservices or sensitive external APIs are particularly at risk. An attacker who can exploit this flaw gains unauthenticated access to protected backend resources that were previously shielded by rigorous client certificate validation. This bypass allows the adversary to perform actions as an authenticated user, potentially leading to data exfiltration, unauthorized configuration changes, or further lateral movement within the network infrastructure. The severity is amplified in complex deployments where multiple services are routed through a single Traefik instance with multi-host rules, as a single misconfiguration or exploitation attempt can expose all associated services simultaneously rather than isolating the breach to one specific domain.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-755: Improper Handling of Exceptional Conditions, specifically regarding how error states in configuration resolution lead to security degradation. In terms of MITRE ATT&CK mapping, this behavior facilitates Initial Access by allowing unauthenticated actors to bypass authentication mechanisms (T1078) and potentially move laterally within the network once inside the perimeter. The exploitation vector relies on the attacker's ability to trigger or exploit the conflict resolution logic, which may be achievable through API interactions if dynamic configuration is enabled without sufficient access controls, or by exploiting known misconfigurations in static files that are processed incorrectly during runtime updates.
To mitigate this risk, organizations running Traefik versions earlier than 2.11.55 must upgrade to the patched version immediately where available. For environments unable to update promptly, a temporary mitigation involves restructuring routing rules to ensure that each hostname requiring strict mutual TLS authentication is assigned its own dedicated router rule rather than sharing a multi-host definition. This isolation prevents the flawed conflict resolution logic from affecting multiple domains simultaneously and ensures that TLS context errors in one route do not cascade into others. Additionally, administrators should audit their Traefik configurations for any dynamic providers that allow untrusted users to modify routing rules or TLS options, as restricting write access to these components can prevent attackers from triggering the vulnerability conditionally. Regular security assessments of ingress controller configurations are recommended to identify similar architectural weaknesses in how TLS contexts are managed across complex multi-host deployments.