Traefik: BasicAuth singleflight key collision allows authenticated identity spoofing
Summary
There is a low severity vulnerability in Traefik's BasicAuth middleware. Concurrent password verifications are deduplicated through a singleflight group whose key was the delimiter-free concatenation of the submitted password and the stored secret, so a request carrying an unconfigured username — whose secret is empty — can produce the same key as a configured user's valid request and receive that request's successful result. Exploitation requires the attacker to already hold a valid credential and to read the stored password hash, which is only reachable through paths that are themselves privileged: the API is documented as admin-only, the Kubernetes path requires read access to the Secret, and the Docker path requires access to the socket. The key now encodes the password length as a prefix, so distinct (password, secret) pairs can no longer collide. Only the v3.6 line from v3.6.11 onwards and the v3.7 line are affected; earlier v3 releases and the v2 line do not carry the vulnerable deduplication path.
Patches
- https://github.com/traefik/traefik/releases/tag/v3.6.25
- https://github.com/traefik/traefik/releases/tag/v3.7.10
For more information
If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).
<details>
<summary>Original Description</summary>
Summary
Traefik's BasicAuth middleware deduplicates concurrent password checks with a
singleflight.Group. Its key is the delimiter-free concatenation
password + secret. For an existing user with password P and stored hash
H, the key is P || H. An unknown user can select the password P || H;
because its secret is the empty string, its key is also P || H.
If the existing user's request starts the shared calculation, the unknown
user receives the existing user's successful Boolean result. Traefik then
continues processing the unknown user's original request and propagates the
attacker-selected username through URL.User, the access log, and the
configured BasicAuth headerField.
A user who knows one valid username/password/hash tuple can therefore
authenticate concurrently under any unconfigured username. This becomes a
privilege escalation when a backend uses the BasicAuth headerField as a
trusted identity, which is the documented purpose of that option.
Details
The vulnerable logic is in
pkg/middlewares/auth/basic_auth.go:118-131:
```go
func (b *basicAuth) checkPassword(user, password string) bool {
secret := b.auth.Secrets(user, b.auth.Realm)
key := 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)
}
```
For a configured user viewer:
```text
password = P
secret = H
key = P || H
result = true
```
For an unconfigured user admin:
```text
password = P || H
secret = ""
key = (P || H) || "" = P || H
```
singleflight.Group.Do shares the first in-flight result for equal keys. If
the configured user's check is first, the unknown user's closure is not run
and the unknown request receives true.
The authorization result is not bound to the username. After the shared
result is accepted, ServeHTTP uses the username parsed from the unknown
request:
```go
req.URL.User = url.User(user)
if b.headerField != "" {
req.Header.Del(b.headerField)
req.Header[b.headerField] = []string{user}
}
```
Consequently, the backend sees the attacker-selected admin identity, not
the valid request's viewer identity.
Attack prerequisites
The attacker needs:
1. network access to a route protected by the affected BasicAuth middleware;
2. one valid low-privilege username and password;
3. the corresponding stored password hash.
The hash is often present in deployment labels or routing configuration.
Traefik's API is also a direct source when the attacker can access it:
GET /api/http/middlewares/{id} serializes basicAuth.users, including the
hash, despite the field carrying loggable:"false". The official v3.7.8
binary returned the hash in the validation environment.
The attacker does not need another user's password or a victim-generated
request. The attacker creates both concurrent requests: one with their valid
credentials and one with an arbitrary, unconfigured target username.
When headerField is configured, an authenticated low-privilege user can
impersonate an arbitrary identity to the backend. Depending on downstream
authorization, this can allow:
- access to administrative data;
- execution of privileged state-changing operations;
- corruption of audit attribution;
- bypass of identity-based tenant or role separation.
Without headerField, the unknown request is still admitted through the
BasicAuth mid
