CVE-2026-88010

Summary

Confirmed. checkPassword derives the singleflight key from the stored secret, so the key encodes whether the submitted username exists:

• username absent, secret == "", key = len(P) + ":" + P
• username present, key = len(P) + ":" + P + secret_T

Every non-existent username therefore lands on one shared key, while every configured username gets its own. singleflight.Group.Do makes a follower on an equal key block on the leader's in-flight computation and return the leader's result. So an attacker who sends a leader request with a junk username and password P, then sends the probe for target T with the same P late inside the leader's window, reads user existence directly off the probe's latency: coalesced (fast) means T does not exist, own hash (slow) means T does exist.

This is the exact information leak that the notFoundSecret dummy hash at line 127 exists to remove. Sequential probing is fully equalised (measured ratio 1.00x, so the fix for cwfr / 8j2h does work); the leak reappears only under attacker-controlled concurrency. Confirmed on the current v3.7 head, which already carries the 8mrf singleflight fix, and on master (no later fix exists).

Affected code

• pkg/middlewares/auth/basic_auth.go:125 (checkPassword)

Code analysis

pkg/middlewares/auth/basic_auth.go:119-131 matches the finding verbatim, including the cited line 125:

func (b *basicAuth) checkPassword(user, password string) bool {   // :119
	secret := b.auth.Secrets(user, b.auth.Realm)                   // "" when the user is absent

	key := strconv.Itoa(len(password)) + ":" + password + secret   // :124
	match, _, _ := b.singleflightGroup.Do(key, func() (any, error) {   // :125
		if secret == "" {
			_ = b.checkSecret(password, b.notFoundSecret)          // :127  dummy hash, equal cost
			return false, nil
		}
		return b.checkSecret(password, secret), nil
	})
	return match.(bool)
}

Two independent properties combine:

1. The dummy hash equalises the cost of one lookup. notFoundSecret is a configured user's real hash (slices.Collect(maps.Values(users))[0]), so absent and present users each perform exactly one hash of the same algorithm and cost. That is why the sequential control below is flat.
2. The key partitions on existence, so coalescing is not equalised. The dummy hash was placed inside the closure (commit 122175ac2, PR #12803), which is what pulls absent users into Do at all. Before that refactor, secret == "" returned false before Do was ever called.

Git archaeology of the whole sequence in this one function:

J15 is the residue of that last fix. It does not depend on the key collision 8mrf closed: the oracle works precisely because the keys differ. The prior analysis of 8mrf recommended keeping "the empty-secret (unconfigured) path out of any key that a configured user can share"; the shipped patch only delimited the key, so the existence dependency survived.

Affected range: >= v3.6.11 (the 122175ac2 refactor) through current v3.7 head and master. Not the v2 line, and not earlier v3 releases, which returned early for absent users. Digest auth does not use singleflight and is unaffected.

Impact scope: username enumeration only. No credential disclosure, no authentication bypass, no result sharing across identities.

Reproduction

Go tests written directly in package auth, driving the real NewBasic handler over a real HTTP server (httptest), with real bcrypt / apr1 hashes and no instrumentation of the vulnerable logic. Files: pkg/middlewares/auth/zz_scanpoc_J15{,b,c}_test.go, deleted after the run.

Commands

cd /Users/emile/go/src/github.com/traefik/traefik
go test -count=1 -run TestZZScanPoCJ15      -v ./pkg/middlewares/auth/...
go test -count=1 -run TestZZScanPoCJ15Costs -v ./pkg/middlewares/auth/...
go test -count=1 -run TestZZScanPoCJ15H2    -v ./pkg/middlewares/auth/...

Probe shape, exactly the claimed scenario: calibrate D with one request, launch a leader with a junk username and password P, sleep 0.9 * D, then send the probe with password P and either a configured (alice) or an absent (bob) username, and time the probe. classify=OK means present > 2 * absent, i.e. the oracle answered correctly.

Observed, main PoC (test 1)

[bcrypt-cost12] SEQUENTIAL control: absent=249.568275ms present=249.10215ms ratio=1.00x
[bcrypt-cost12] CONCURRENT D=245.521625ms frac=0.90 round 0: absent=21.750833ms present=242.081792ms ratio=11.1x  classify=OK
[bcrypt-cost12] CONCURRENT D=245.521625ms frac=0.90 round 1: absent=20.197667ms present=245.234958ms ratio=12.1x  classify=OK
[bcrypt-cost12] CONCURRENT D=245.521625ms frac=0.90 round 2: absent=25.675958ms present=243.981375ms ratio=9.5x   classify=OK
[bcrypt-cost10] SEQUENTIAL control: absent=61.4374ms present=61.049608ms ratio=0.99x
[bcrypt-cost10] CONCURRENT D=60.54675ms frac=0.90 round 0: absent=5.572875ms present=60.8345ms   ratio=10.9x  classify=OK
[bcrypt-cost10] CONCURRENT D=60.54675ms frac=0.90 round 1: absent=4.042292ms present=61.988792ms ratio=15.3x  classify=OK
[bcrypt-cost10] CONCURRENT D=60.54675ms frac=0.90 round 2: absent=4.53825ms  present=61.557791ms ratio=13.6x  classify=OK
[apr1-short-pw] SEQUENTIAL control: absent=360.7µs present=373.116µs ratio=1.03x
[apr1-short-pw] CONCURRENT D=370.792µs frac=0.90 round 0: absent=378.167µs present=409.458µs ratio=1.1x  classify=FAIL
[apr1-short-pw] CONCURRENT D=370.792µs frac=0.90 round 1: absent=352.416µs present=333.875µs ratio=0.9x  cl