GoFiber Vulnerable to Username Enumeration via Timing Oracle in BasicAuth Default AuthorizerGHSA-g5vh-55hw-rxm8
MEDIUMGHSA-g5vh-55hw-rxm8 is a medium-severity (CVSS 5.3) CWE-203 vulnerability in github.com/gofiber/fiber/v3. A fix is available for github.com/gofiber/fiber/v3 — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-g5vh-55hw-rxm8.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-g5vh-55hw-rxm8 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/gofiber/fiber/v3Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The default Authorizer function in GoFiber's BasicAuth middleware uses short-circuit evaluation that skips password hash comparison for non-existent usernames. With bcrypt-hashed passwords (the primary use case), the timing difference between a valid and invalid username is approximately 1,000,000:1 (~100ms vs ~100ns), enabling reliable remote username enumeration.
Vulnerable Code
File: middleware/basicauth/config.go, lines 126-138
if cfg.Authorizer == nil {
verifiers := make(map[string]func(string) bool, len(cfg.Users))
for u, hpw := range cfg.Users {
v, err := parseHashedPassword(hpw)
if err != nil {
panic(err)
}
verifiers[u] = v
}
cfg.Authorizer = func(user, pass string, _ fiber.Ctx) bool {
verify, ok := verifiers[user]
return ok && verify(pass) // line 137: short-circuit skips verify() if user unknown
}
}
Data Flow
- Attacker sends
Authorization: Basic <base64(candidate:wrongpass)> - BasicAuth middleware decodes credentials and calls
cfg.Authorizer(user, pass, c) - Map lookup
verifiers[user]returnsok=falsefor non-existent users - Go
&&short-circuit:false && verify(pass)returns immediately without callingverify() - For valid users,
verify(pass)executesbcrypt.CompareHashAndPassword()(line 167: ~100ms at default cost 10) - Timing difference: ~100ns (invalid user) vs ~100ms (valid user) = 1,000,000:1 ratio
Timing comparison by hash type:
| Hash Type | Valid User | Invalid User | Ratio |
|---|---|---|---|
| bcrypt ($2) | ~100 ms | ~100 ns | 1,000,000:1 |
| SHA-512 | ~1-5 us | ~100 ns | 10-50:1 |
| SHA-256 | ~1-5 us | ~100 ns | 10-50:1 |
Impact
- Username enumeration: Attacker reliably determines which usernames exist by measuring response latency
- Targeted brute force: After enumerating valid usernames, password brute force is focused only on real accounts
- Account discovery: In applications where usernames are sensitive (internal tools, admin panels), leaking their existence is itself a security issue
Notes
- Password hash comparisons themselves are timing-safe:
subtle.ConstantTimeCompareis used correctly for SHA-256 (line 185), SHA-512 (line 176), and bcrypt uses its own constant-time comparison - The fix is to always execute a dummy hash comparison for unknown users:
bcrypt.CompareHashAndPassword(dummyHash, []byte(pass))and discard the result - This pattern matches CVE-2023-36456 (Authentik timing oracle) and similar findings in other auth libraries
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/gofiber/fiber/v3 | all versions | 3.3.0go get github.com/gofiber/fiber/v3@v3.3.0 |
Affected Products
fibergofiberDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gofiber/fiber/v3, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/gofiber/fiber/v3 to 3.3.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-g5vh-55hw-rxm8 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-g5vh-55hw-rxm8 in your dependencies?
Find it across Go, including transitive dependencies.