CVE-2026-88010: Unauthenticated Username-Enumeration Timing Oracle in Traefik BasicAuth Middleware

Traefik is an open-source HTTP reverse proxy and load balancer widely utilized in modern cloud-native environments. To handle inbound traffic securely, Traefik includes a BasicAuth middleware that validates user credentials before forwarding traffic to upstream services. Because authentication verification relies on resource-heavy cryptographic hashing algorithms (such as bcrypt), the middleware is exposed to CPU exhaustion vectors. To protect system resources from parallel verification attacks, Traefik integrates Go's singleflight deduplication module.

Under normal execution, the singleflight mechanism blocks concurrent identical verification requests, resolves them with a single cryptographic check, and shares the verdict. However, from version 3.6.11 to 3.7.12, a severe structural flaw exists in how the singleflight lookup key is generated. This vulnerability exposes an observable timing discrepancy (CWE-208), allowing unauthenticated remote actors to determine the existence of specific configuration credentials.

While this timing oracle does not directly expose user passwords or bypass authentication mechanisms, it strips away the anonymity of system configurations. Attackers can leverage this capability to map out administrative and user accounts. This initial information collection facilitates subsequent, highly targeted brute-force and credential-stuffing campaigns against the deployment infrastructure.

The root cause of CVE-2026-88010 resides within the checkPassword function of Traefik's basic authentication middleware located at pkg/middlewares/auth/basic_auth.go. When a request arrives, the middleware must compute the cryptographic hash of the provided password and compare it to the stored secret. To optimize execution, Traefik wraps this calculation in a singleflightGroup.Do() block, which takes a string key to uniquely identify the workload.

The deduplication key is formulated as: key := strconv.Itoa(len(password)) + ":" + password + secret. Here, secret represents the server-configured hash retrieved via b.auth.Secrets(user). If the target username does not exist in the configuration database, the lookup returns an empty string (""). This causes the generated key to omit any user-specific identifiers, collapsing down to: len(password):password.

Because the key generation for non-existent users depends entirely on the attacker-supplied password, concurrent requests for different invalid usernames share the same key. The singleflight system intercepts these duplicate keys and coalesces them, executing only a single hash computation. Conversely, when a valid username is queried, its corresponding non-empty secret hash is appended to the key, generating a unique entry that bypasses coalescence. This logical divergence creates a reliable side-channel timing difference.

To understand the vulnerability mechanics and the subsequent remediation, we must examine the vulnerable code side-by-side with the official patch implemented in commit ddc1bf4660b85fd61fafdd821eb8216fb1a0b130.

In the vulnerable implementation, the application relies on the configuration state (secret) to differentiate the execution tracks within the deduplication library:

// VULNERABLE CODE PATH
func (b *basicAuth) checkPassword(user, password string) bool {
    secret := b.auth.Secrets(user, b.auth.Realm)
 
    // The addition of 'secret' here leaks user existence.
    // If secret is empty, the key is identical across different invalid users.
    key := strconv.Itoa(len(password)) + ":" + password + secret
    match, _, _ := b.singleflightGroup.Do(key, func() (any, error) {
        if secret == "" {
            _ = b.checkSecret(password, b.notFoundSecret)
            return false, nil
        }
        return b.checkSecret(password, secret), nil
    })
    return match.(bool)
}

The patch addresses this issue by removing the server-configured secret from the singleflight key generation entirely. Instead, a dedicated function named singleflightKey constructs the deduplication key utilizing only client-controlled parameters:

// PATCHED CODE PATH
func (b *basicAuth) checkPassword(user, password string) bool {
    secret := b.auth.Secrets(user, b.auth.Realm)
 
    // Key is generated purely on client-supplied input via singleflightKey
    match, _, _ := b.singleflightGroup.Do(singleflightKey(user, password), func() (any, error) {
        if secret == "" {
            _ = b.checkSecret(password, b.notFoundSecret)
            return false, nil
        }
        return b.checkSecret(password, secret), nil
    })
    return match.(bool)
}
 
func singleflightKey(user, password string) string {
    // Length-prefix avoids delimiter injection while retaining uniqueness per user.
    return strconv.Itoa(len(user)) + ":" + user + ":" + password
}

By prefixing the username length and concatenating the actual username, the keys for unknown1 and unknown2 remain structurally distinct: 8:unknown1:password versus 8:unknown2:password. This prevents any possibility of cross-user coalescence. Additionally, retaining the username inside the singleflight key is critical; completely omitting the username would let an attacker pass credentials for one user and receive the authentication verdict belonging to another (as detailed in GHSA-6765-c87h-8mrf). The fix is complete and robust against variant exploitation pathways.

Exploiting this timing oracle requires the coordination of concurrent HTTP requests. The objective is to measure whether a targeted probe request coalesces with an ongoing anchor request. Because the singleflight mechanism works in-memory on the active proxy, the attacker must send the anchor and probe requests in extremely close succession.

First, the attacker establishes a network latency baseline by sending multiple sequential authentication requests containing invalid usernames. Each request forces the proxy to run a dummy cryptographic comparison using the default fallback hash, resulting in a stable response latency ($T_{hash}$).

Second, the attacker initiates an active probe sequence. The attacker transmits an 'Anchor' request containing a known invalid username and a specific password. This request initiates the server-side dummy hashing routine, which takes $T_{hash}$ to complete. While this request is active, the attacker immediately sends a concurrent 'Probe' request containing the target username and the identical password.

If the target username is valid, the proxy generates a unique key, and the request is computed independently, taking the full $T_{hash}$ duration. However, if the target username is invalid, both requests generate the same singleflight key. The Probe request immediately coalesces with the Anchor request, blocking until the Anchor finishes. Consequently, both requests complete at nearly the same time, giving the Probe a response duration significantly shorter than the baseline ($T_{probe} < T_{hash} / 2$). By analyzing this differential across multiple cycles, attackers can reliably map the configuration landscape.

The impact of CVE-2026-88010 is classified as Medium, receiving a CVSS v4.0 base score of 6.3. The vulnerability is restricted to information disclosure, specifically exposing valid authentication usernames configured within Traefik's BasicAuth middleware. It does not allow for credential harvesting, authentication bypass, or arbitrary code execution on the target server.

Nonetheless, username enumeration represents a critical step in the cyber kill chain. In environments where basic authentication protects sensitive management API endpoints (such as the Traefik Dashboard or administrative backends), revealing valid usernames significantly narrows the scope of credential-stuffing attacks. This allows adversaries to optimize brute-force resources on verified accounts, bypassing account lockout mechanisms or avoiding detection by reducing noise.

Because the vulnerability requires the execution of tightly coordinated concurrent requests, it is highly sensitive to network latency, packet loss, and connection jitter. Consequently, exploitation is most practical over low-latency connections or when launched from within the same cloud region. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities catalog, and there are currently no reports of exploitation in the wild.

The primary remediation for this vulnerability is to upgrade Traefik deployments to version 3.7.13 or newer. This version contains the updated key-generation logic that isolates each username in its own singleflight execution thread.

If upgrading is not immediately possible, several effective workarounds can reduce the risk. Organizations can transition from Basic Authentication to Digest Authentication within their Traefik middleware configurations. Digest Authentication is structurally unaffected by this timing oracle. Alternatively, deploying rate-limiting policies at the network boundary or Web Application Firewall (WAF) layer can disrupt the rapid, concurrent connections required to perform timing analysis.

Security teams can verify vulnerability remediation by deploying the unit test pattern established in the Traefik codebase. This test isolates the password verification callback, runs concurrent checks for distinct invalid usernames, and verifies that two independent hashing computations are recorded. If only one hashing computation is observed under concurrent conditions, the system remains vulnerable.