Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-g5vh-55hw-rxm8

MEDIUM

GoFiber Vulnerable to Username Enumeration via Timing Oracle in BasicAuth Default Authorizer

Also known asCVE-2026-44332GO-2026-5886
Published
Jul 2, 2026
Updated
Jul 24, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
🐹github.com/gofiber/fiber/v3

Real-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

  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 TypeValid UserInvalid UserRatio
bcrypt ($2)~100 ms~100 ns1,000,000:1
SHA-512~1-5 us~100 ns10-50:1
SHA-256~1-5 us~100 ns10-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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/gofiber/fiber/v3all versions3.3.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gofiber/fiber/v3. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. 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.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-g5vh-55hw-rxm8 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-g5vh-55hw-rxm8. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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 {
O3 Security · Impact-Aware SCA

Is GHSA-g5vh-55hw-rxm8 in your dependencies?

O3 detects GHSA-g5vh-55hw-rxm8 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.