GitHub Security Advisory: GHSA-qr99-7898-vr7c
Package: github.com/traefik/traefik/v3 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: >= 3.0.0-beta1, < 3.6.11
Patched in: 3.6.12

Summary: Traefik Vulnerable to BasicAuth/DigestAuth Identity Spoofing via Non-Canonical headerField

Details:
## Summary

There is a potential vulnerability in Traefik's Basic and Digest authentication middlewares when `headerField` is configured with a non-canonical HTTP header name.

An authenticated attacker with valid credentials can inject the canonical version of the configured header to impersonate any identity to the backend. Because Traefik writes the authenticated username using a non-canonical map key, it creates a separate header entry rather than overwriting the attacker's canonical one — causing most backend frameworks to read the attacker-controlled value instead.

## Patches

- <https://github.com/traefik/traefik/releases/tag/v2.11.42>
- <https://github.com/traefik/traefik/releases/tag/v3.6.12>
- <https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3>

## For more information

If there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).

---

<details>
<summary>Original Description</summary>

### Summary

When `headerField` is configured with a non-canonical HTTP header name (e.g., `x-auth-user` instead of `X-Auth-User`), an authenticated attacker can inject a canonical version of that header to impersonate any identity to the backend. The backend receives two header entries — the attacker-injected canonical one is read first, overriding Traefik's non-canonical write.

Tested on Traefik v3.6.10.

### Details

At `pkg/middlewares/auth/basic_auth.go:92`, the authenticated username is written using direct map assignment:

```go
req.Header[b.headerField] = []string{user}
```

Go's `http.Header` map is keyed by canonical names (e.g., `X-Auth-User`). Direct assignment with a non-canonical key (`x-auth-user`) creates a separate map entry from any canonical-key entry already present. The attacker's `X-Auth-User: superadmin` occupies the canonical slot and is never overwritten by Traefik's non-canonical write.

The same bug exists in `pkg/middlewares/auth/digest_auth.go:100`. Notably, `forward.go:254` correctly uses `http.CanonicalHeaderKey()`, showing the fix pattern already exists in the codebase.

### PoC

**Traefik config (YAML, Docker labels, or REST API):**

```yaml
middlewares:
  auth:
    basicAuth:
      users: ["admin:$2y$05$..."]
      headerField: "x-auth-user"
```

**Normal request (baseline):**

```bash
curl -u admin:admin http://traefik/secure/test
# Backend receives: x-auth-user: admin
# Identity = admin ✓
```

**Attack request:**

```bash
curl -u admin:admin -H "X-Auth-User: superadmin" http://traefik/secure/test
# Backend receives BOTH headers:
#   X-Auth-User: superadmin   ← attacker-injected (canonical key, read first by most frameworks)
#   x-auth-user: admin        ← Traefik-set (non-canonical, ignored by most frameworks)
# Identity seen by backend = superadmin ✗
```

**Control test** — when `headerField` uses canonical casing (`X-Auth-User`), the attack fails. Traefik's write correctly overwrites the attacker's header.

This is realistic because YAML con