CVE-2026-85595 in Traefik
Summary
by MITRE • 09/04/2026
Traefik versions before v2.11.55 contain an authentication bypass vulnerability in the digestAuth middleware where unknown usernames receive an empty secret instead of rejection. Attackers can compute a valid digest response using the empty secret and arbitrary credentials to bypass authentication on any digestAuth-protected route without a valid username or password.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The identified security flaw resides within the Traefik reverse proxy software, specifically affecting versions prior to v2.11.55 in its implementation of the HTTP Digest Authentication middleware. This vulnerability stems from an improper handling of authentication requests where the system fails to properly validate the existence or validity of a username before proceeding with cryptographic verification steps. In standard digest authentication protocols, such as those defined by RFC 7616, the server must possess the pre-shared secret associated with the provided username to compute and verify the response hash. However, in this flawed implementation, when an attacker submits a request containing an unknown or non-existent username, Traefik does not immediately reject the connection due to invalid credentials. Instead, it proceeds to generate a digest response using an empty string as the pre-shared secret for that user. This deviation from secure authentication practices creates a critical bypass mechanism that undermines the integrity of access controls applied via this middleware.
From a technical perspective, the core issue is rooted in how the server constructs the HA1 hash value used during the challenge-response exchange. Normally, if a username is not found in the credential store, the authentication process should terminate with an unauthorized error code, typically HTTP 401 Unauthorized. By returning an empty secret instead of rejecting the request outright, Traefik allows attackers to compute valid digest responses using arbitrary credentials against this null value. Since the server accepts these computed hashes as valid for any provided username, including those that do not exist in its configuration, the authentication mechanism is effectively neutralized. This behavior indicates a failure in input validation and state management within the middleware logic, where the assumption that all incoming usernames are pre-registered or validated before cryptographic operations was incorrectly applied.
The operational impact of this vulnerability is severe for any infrastructure relying on Traefik to protect backend services with digest authentication. Attackers can bypass access controls entirely without needing valid credentials, effectively gaining unauthorized entry to protected routes and APIs. This could lead to data exfiltration, privilege escalation if the underlying applications have further vulnerabilities, or complete compromise of sensitive systems exposed through the proxy. The ease of exploitation is high because it requires no complex payload crafting beyond standard HTTP headers; an attacker simply needs to send a request with any username and compute the corresponding digest hash using common tools or scripts that support MD5 hashing algorithms. This makes automated scanning and large-scale attacks feasible against vulnerable deployments, particularly those exposing internal management interfaces or sensitive microservices directly through Traefik ingress points.
This vulnerability aligns closely with CWE-287 Improper Authentication, as it represents a failure in the system to correctly verify identity before granting access. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, although in this specific case, the attacker is bypassing the need for valid accounts altogether by exploiting the authentication logic itself rather than stealing credentials. The flaw highlights the dangers of assuming default behaviors or edge cases are handled securely without explicit validation checks. To mitigate this risk, organizations running Traefik must upgrade to version v2.11.55 or later immediately where this issue has been patched. Until an upgrade is possible, administrators should consider implementing additional layers of authentication such as OAuth2 proxies or IP-based access control lists at the network perimeter to compensate for the weakness in the digest middleware. Regular audits of authentication configurations and adherence to least privilege principles are essential to minimize exposure while remediation efforts proceed.