GHSA-G5VH-55HW-RXM8

Vulnerability from github – Published: 2026-07-02 13:46 – Updated: 2026-07-02 13:46
VLAI
Summary
GoFiber Vulnerable to Username Enumeration via Timing Oracle in BasicAuth Default Authorizer
Details

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 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
Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.2.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gofiber/fiber/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44332"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-203"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T13:46:25Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe default `Authorizer` function in GoFiber\u0027s 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.\n\n## Vulnerable Code\n\n**File:** `middleware/basicauth/config.go`, lines 126-138\n\n```go\nif cfg.Authorizer == nil {\n    verifiers := make(map[string]func(string) bool, len(cfg.Users))\n    for u, hpw := range cfg.Users {\n        v, err := parseHashedPassword(hpw)\n        if err != nil {\n            panic(err)\n        }\n        verifiers[u] = v\n    }\n    cfg.Authorizer = func(user, pass string, _ fiber.Ctx) bool {\n        verify, ok := verifiers[user]\n        return ok \u0026\u0026 verify(pass)   // line 137: short-circuit skips verify() if user unknown\n    }\n}\n```\n\n## Data Flow\n\n1. Attacker sends `Authorization: Basic \u003cbase64(candidate:wrongpass)\u003e`\n2. BasicAuth middleware decodes credentials and calls `cfg.Authorizer(user, pass, c)`\n3. Map lookup `verifiers[user]` returns `ok=false` for non-existent users\n4. Go `\u0026\u0026` short-circuit: `false \u0026\u0026 verify(pass)` returns immediately without calling `verify()`\n5. For valid users, `verify(pass)` executes `bcrypt.CompareHashAndPassword()` (line 167: ~100ms at default cost 10)\n6. Timing difference: ~100ns (invalid user) vs ~100ms (valid user) = 1,000,000:1 ratio\n\n**Timing comparison by hash type:**\n\n| Hash Type | Valid User | Invalid User | Ratio |\n|-----------|-----------|--------------|-------|\n| bcrypt ($2) | ~100 ms | ~100 ns | 1,000,000:1 |\n| SHA-512 | ~1-5 us | ~100 ns | 10-50:1 |\n| SHA-256 | ~1-5 us | ~100 ns | 10-50:1 |\n\n## Impact\n\n- **Username enumeration:** Attacker reliably determines which usernames exist by measuring response latency\n- **Targeted brute force:** After enumerating valid usernames, password brute force is focused only on real accounts\n- **Account discovery:** In applications where usernames are sensitive (internal tools, admin panels), leaking their existence is itself a security issue\n\n## Notes\n\n- 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\n- The fix is to always execute a dummy hash comparison for unknown users: `bcrypt.CompareHashAndPassword(dummyHash, []byte(pass))` and discard the result\n- This pattern matches CVE-2023-36456 (Authentik timing oracle) and similar findings in other auth libraries",
  "id": "GHSA-g5vh-55hw-rxm8",
  "modified": "2026-07-02T13:46:25Z",
  "published": "2026-07-02T13:46:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gofiber/fiber/security/advisories/GHSA-g5vh-55hw-rxm8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gofiber/fiber"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "GoFiber Vulnerable to Username Enumeration via Timing Oracle in BasicAuth Default Authorizer"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.