## 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 ```go 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 1. Attacker sends `Authorization: Basic <base64(candidate:wrongpass)>` 2. BasicAuth middleware decodes credentials and calls `cfg.Authorizer(user, pass, c)` 3. Map lookup `verifiers[user]` returns `ok=false` for non-existent users 4. Go `&&` short-circuit: `false && verify(pass)` returns immediately without calling `verify()` 5. For valid users, `verify(pass)` executes `bcrypt.CompareHashAndPassword()` (line 167: ~100ms at default cost 10) 6. 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.ConstantTimeCompare` is 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
## 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 ```go 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 1. Attacker sends `Authorization: Basic <base64(candidate:wrongpass)>` 2. BasicAuth middleware decodes credentials and calls `cfg.Authorizer(user, pass, c)` 3. Map lookup `verifiers[user]` returns `ok=false` for non-existent users 4. Go `&&` short-circuit: `false && verify(pass)` returns immediately without calling `verify()` 5. For valid users, `verify(pass)` executes `bcrypt.CompareHashAndPassword()` (line 167: ~100ms at default cost 10) 6. 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.ConstantTimeCompare` is 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
Update github.com/gofiber/fiber/v3 to 3.3.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanGoFiber Vulnerable to Username Enumeration via Timing Oracle in BasicAuth Default Authorizer affects github.com/gofiber/fiber/v3 (go). Severity is medium. ## 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 ```go 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 1. Attacker sends `Authorization: Basic <base64(candidate:wrongpass)>` 2. BasicAuth middleware decodes credentials and calls `cfg.Authorizer(user, pass, c)` 3. Map lookup `verifiers[user]` returns `ok=false` for non-existent users 4. Go `&&` short-circuit: `false && verify(pass)` returns immediately without calling `verify()` 5. For valid users, `verify(pass)` executes `bcrypt.CompareHashAndPassword()` (line 167: ~100ms at default cost 10) 6. 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.ConstantTimeCompare` is 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
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/gofiber/fiber/v3go | <=3.2.0 | 3.3.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/gofiber/fiber/v3 to 3.3.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanGoFiber Vulnerable to Username Enumeration via Timing Oracle in BasicAuth Default Authorizer affects github.com/gofiber/fiber/v3 (go). Severity is medium. ## 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 ```go 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 1. Attacker sends `Authorization: Basic <base64(candidate:wrongpass)>` 2. BasicAuth middleware decodes credentials and calls `cfg.Authorizer(user, pass, c)` 3. Map lookup `verifiers[user]` returns `ok=false` for non-existent users 4. Go `&&` short-circuit: `false && verify(pass)` returns immediately without calling `verify()` 5. For valid users, `verify(pass)` executes `bcrypt.CompareHashAndPassword()` (line 167: ~100ms at default cost 10) 6. 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.ConstantTimeCompare` is 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
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/gofiber/fiber/v3go | <=3.2.0 | 3.3.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard