GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

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
Show details on source website

{
  "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.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…