Vulnerability-Lookup

GHSA-CR7P-CR3Q-H5CM

Vulnerability from github – Published: 2026-07-24 21:43 – Updated: 2026-08-12 18:56

Summary

Budibase: Account Enumeration via Login Lockout Response Differential

Details

Summary

The login lockout mechanism in Budibase creates an observable response discrepancy that allows unauthenticated attackers to enumerate valid email addresses. When an existing user's account is locked after 5 failed login attempts, the server returns a distinct 403 response with X-Account-Locked: 1 and Retry-After: 900 headers plus the message "Account temporarily locked." For non-existing users, the response is always a generic 403 "Unauthorized" regardless of attempt count, because the lockout counter is never incremented.

Details

The vulnerability exists in two files that implement the login lockout feature:

packages/worker/src/middleware/lockout.ts:18-36 — The lockout middleware only blocks requests for users that exist in the database AND are locked:

export default async (ctx: Ctx, next: Next) => {
  const email = ctx.request.body.username
  if (!email) {
    return await next()
  }
  const dbUser = await userSdk.db.getUserByEmail(email)
  if (dbUser && (await isLocked(email))) {  // line 26: non-existing users skip this entirely
    ctx.set("X-Account-Locked", "1")
    ctx.set("Retry-After", String(env.LOGIN_LOCKOUT_SECONDS))
    ctx.throw(403, "Account temporarily locked. Try again later.")
  }
  return await next()
}

packages/worker/src/api/controllers/global/auth.ts:127-141 — The login handler only increments the failure counter for existing users:

if (err || !user) {
  if (dbUser) {          // line 129: non-existing users never trigger onFailed()
    await onFailed(email)
  }
  if (await isLocked(email)) {
    return handleLockoutResponse(ctx, email)
  }
  // ...
  return passportCallback(ctx, user as any, err, info)
}

Execution flow for existing users (after 5 failed attempts): 1. lockout middleware → getUserByEmail returns user → isLocked returns true → 403 + X-Account-Locked: 1 + Retry-After: 900 + "Account temporarily locked"

Execution flow for non-existing users (any number of attempts): 1. lockout middleware → getUserByEmail returns null → dbUser && isLocked is false → passes through 2. Login handler → passport fails → if (dbUser) is false → onFailed() never called → lock never set 3. Always returns 403 "Unauthorized"

No IP-based rate limiting exists on the login endpoint (POST /api/global/auth/:tenantId/login). The route is registered via loggedInRoutes which applies no authentication middleware. The password reset endpoint has proper IP-based rate limiting, but the login endpoint does not.

PoC

# Test against a known-existing email and a non-existing email
# Replace 'default' with the target tenant ID

# Step 1: Send 6 login attempts for an existing user
echo "=== Testing existing user ==="
for i in $(seq 1 6); do
  echo "--- Attempt $i ---"
  curl -s -D - -X POST http://localhost:10000/api/global/auth/default/login \
    -H 'Content-Type: application/json' \
    -d '{"username":"local@budibase.com","password":"wrongpassword"}' 2>&1 \
    | grep -E 'HTTP/|X-Account-Locked|Retry-After|locked|Unauthorized'
  echo ""
done

# Expected: Attempts 1-5 return "Unauthorized"
# Attempt 6 returns: "Account temporarily locked" + X-Account-Locked: 1 + Retry-After: 900

# Step 2: Send 6 login attempts for a non-existing user
echo "=== Testing non-existing user ==="
for i in $(seq 1 6); do
  echo "--- Attempt $i ---"
  curl -s -D - -X POST http://localhost:10000/api/global/auth/default/login \
    -H 'Content-Type: application/json' \
    -d '{"username":"nonexistent@example.com","password":"wrongpassword"}' 2>&1 \
    | grep -E 'HTTP/|X-Account-Locked|Retry-After|locked|Unauthorized'
  echo ""
done

# Expected: All 6 attempts return "Unauthorized" — no lockout ever triggers

# The difference in behavior after 5 attempts confirms whether the email exists.

Impact

Account enumeration: An unauthenticated attacker can determine whether any email address is registered on a Budibase tenant by sending 5-6 login requests and observing whether the response changes to "Account temporarily locked" with the X-Account-Locked header.
No rate limiting: The login endpoint has no IP-based rate limiting, allowing an attacker to enumerate emails at high speed from a single IP address (~5 requests per email).
Denial of service side-effect: Each enumerated existing email is locked out for 15 minutes (900 seconds), preventing legitimate users from logging in during that window.
Enables further attacks: Confirmed valid emails can be used for targeted phishing, credential stuffing against other services, or social engineering.

Recommended Fix

The lockout behavior should be identical regardless of whether the user exists. Apply lockout tracking based on the email string itself, not conditioned on database user existence:

packages/worker/src/middleware/lockout.ts — Remove the dbUser check:

export default async (ctx: Ctx, next: Next) => {
  const email = ctx.request.body.username
  if (!email) {
    return await next()
  }
  // Check lock status based on email alone, not user existence
  if (await isLocked(email)) {
    ctx.set("X-Account-Locked", "1")
    ctx.set("Retry-After", String(env.LOGIN_LOCKOUT_SECONDS))
    ctx.throw(403, "Account temporarily locked. Try again later.")
  }
  return await next()
}

packages/worker/src/api/controllers/global/auth.ts — Remove the dbUser guard around onFailed:

if (err || !user) {
  // Always increment failure counter regardless of user existence
  await onFailed(email)
  if (await isLocked(email)) {
    return handleLockoutResponse(ctx, email)
  }
  // ...
}

Additionally, consider adding IP-based rate limiting to the login endpoint (similar to what already exists on the password reset endpoint) to limit enumeration throughput.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.38.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-204"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:43:11Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe login lockout mechanism in Budibase creates an observable response discrepancy that allows unauthenticated attackers to enumerate valid email addresses. When an existing user\u0027s account is locked after 5 failed login attempts, the server returns a distinct `403` response with `X-Account-Locked: 1` and `Retry-After: 900` headers plus the message \"Account temporarily locked.\" For non-existing users, the response is always a generic `403 \"Unauthorized\"` regardless of attempt count, because the lockout counter is never incremented.\n\n## Details\n\nThe vulnerability exists in two files that implement the login lockout feature:\n\n**`packages/worker/src/middleware/lockout.ts:18-36`** \u2014 The lockout middleware only blocks requests for users that exist in the database AND are locked:\n\n```typescript\nexport default async (ctx: Ctx, next: Next) =\u003e {\n  const email = ctx.request.body.username\n  if (!email) {\n    return await next()\n  }\n  const dbUser = await userSdk.db.getUserByEmail(email)\n  if (dbUser \u0026\u0026 (await isLocked(email))) {  // line 26: non-existing users skip this entirely\n    ctx.set(\"X-Account-Locked\", \"1\")\n    ctx.set(\"Retry-After\", String(env.LOGIN_LOCKOUT_SECONDS))\n    ctx.throw(403, \"Account temporarily locked. Try again later.\")\n  }\n  return await next()\n}\n```\n\n**`packages/worker/src/api/controllers/global/auth.ts:127-141`** \u2014 The login handler only increments the failure counter for existing users:\n\n```typescript\nif (err || !user) {\n  if (dbUser) {          // line 129: non-existing users never trigger onFailed()\n    await onFailed(email)\n  }\n  if (await isLocked(email)) {\n    return handleLockoutResponse(ctx, email)\n  }\n  // ...\n  return passportCallback(ctx, user as any, err, info)\n}\n```\n\n**Execution flow for existing users (after 5 failed attempts):**\n1. `lockout` middleware \u2192 `getUserByEmail` returns user \u2192 `isLocked` returns true \u2192 403 + `X-Account-Locked: 1` + `Retry-After: 900` + \"Account temporarily locked\"\n\n**Execution flow for non-existing users (any number of attempts):**\n1. `lockout` middleware \u2192 `getUserByEmail` returns null \u2192 `dbUser \u0026\u0026 isLocked` is false \u2192 passes through\n2. Login handler \u2192 passport fails \u2192 `if (dbUser)` is false \u2192 `onFailed()` never called \u2192 lock never set\n3. Always returns 403 \"Unauthorized\"\n\nNo IP-based rate limiting exists on the login endpoint (`POST /api/global/auth/:tenantId/login`). The route is registered via `loggedInRoutes` which applies no authentication middleware. The password reset endpoint has proper IP-based rate limiting, but the login endpoint does not.\n\n## PoC\n\n```bash\n# Test against a known-existing email and a non-existing email\n# Replace \u0027default\u0027 with the target tenant ID\n\n# Step 1: Send 6 login attempts for an existing user\necho \"=== Testing existing user ===\"\nfor i in $(seq 1 6); do\n  echo \"--- Attempt $i ---\"\n  curl -s -D - -X POST http://localhost:10000/api/global/auth/default/login \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"username\":\"local@budibase.com\",\"password\":\"wrongpassword\"}\u0027 2\u003e\u00261 \\\n    | grep -E \u0027HTTP/|X-Account-Locked|Retry-After|locked|Unauthorized\u0027\n  echo \"\"\ndone\n\n# Expected: Attempts 1-5 return \"Unauthorized\"\n# Attempt 6 returns: \"Account temporarily locked\" + X-Account-Locked: 1 + Retry-After: 900\n\n# Step 2: Send 6 login attempts for a non-existing user\necho \"=== Testing non-existing user ===\"\nfor i in $(seq 1 6); do\n  echo \"--- Attempt $i ---\"\n  curl -s -D - -X POST http://localhost:10000/api/global/auth/default/login \\\n    -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"username\":\"nonexistent@example.com\",\"password\":\"wrongpassword\"}\u0027 2\u003e\u00261 \\\n    | grep -E \u0027HTTP/|X-Account-Locked|Retry-After|locked|Unauthorized\u0027\n  echo \"\"\ndone\n\n# Expected: All 6 attempts return \"Unauthorized\" \u2014 no lockout ever triggers\n\n# The difference in behavior after 5 attempts confirms whether the email exists.\n```\n\n## Impact\n\n- **Account enumeration**: An unauthenticated attacker can determine whether any email address is registered on a Budibase tenant by sending 5-6 login requests and observing whether the response changes to \"Account temporarily locked\" with the `X-Account-Locked` header.\n- **No rate limiting**: The login endpoint has no IP-based rate limiting, allowing an attacker to enumerate emails at high speed from a single IP address (~5 requests per email).\n- **Denial of service side-effect**: Each enumerated existing email is locked out for 15 minutes (900 seconds), preventing legitimate users from logging in during that window.\n- **Enables further attacks**: Confirmed valid emails can be used for targeted phishing, credential stuffing against other services, or social engineering.\n\n## Recommended Fix\n\nThe lockout behavior should be identical regardless of whether the user exists. Apply lockout tracking based on the email string itself, not conditioned on database user existence:\n\n**`packages/worker/src/middleware/lockout.ts`** \u2014 Remove the `dbUser` check:\n\n```typescript\nexport default async (ctx: Ctx, next: Next) =\u003e {\n  const email = ctx.request.body.username\n  if (!email) {\n    return await next()\n  }\n  // Check lock status based on email alone, not user existence\n  if (await isLocked(email)) {\n    ctx.set(\"X-Account-Locked\", \"1\")\n    ctx.set(\"Retry-After\", String(env.LOGIN_LOCKOUT_SECONDS))\n    ctx.throw(403, \"Account temporarily locked. Try again later.\")\n  }\n  return await next()\n}\n```\n\n**`packages/worker/src/api/controllers/global/auth.ts`** \u2014 Remove the `dbUser` guard around `onFailed`:\n\n```typescript\nif (err || !user) {\n  // Always increment failure counter regardless of user existence\n  await onFailed(email)\n  if (await isLocked(email)) {\n    return handleLockoutResponse(ctx, email)\n  }\n  // ...\n}\n```\n\nAdditionally, consider adding IP-based rate limiting to the login endpoint (similar to what already exists on the password reset endpoint) to limit enumeration throughput.",
  "id": "GHSA-cr7p-cr3q-h5cm",
  "modified": "2026-08-12T18:56:22Z",
  "published": "2026-07-24T21:43:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-cr7p-cr3q-h5cm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/pull/19108"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/commit/eaae816ab81615c07eb10e4619af078d00e2a706"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.39.25"
    }
  ],
  "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": " Budibase: Account Enumeration via Login Lockout Response Differential"
}

CVE-2026-73306 (GCVE-0-2026-73306)

Vulnerability from cvelistv5 – Published: 2026-08-12 18:56 – Updated: 2026-08-13 12:18

Title

Budibase: Account Enumeration via Login Lockout Response Differential

Summary

Budibase is an open-source low-code platform. Prior to 3.39.25, POST /api/global/auth/:tenantId/login incremented the failure counter in packages/worker/src/api/controllers/global/auth.ts only for existing users, while packages/worker/src/middleware/emailLockout.ts returned X-Account-Locked and Retry-After only for locked identifiers. An unauthenticated attacker could compare the response after repeated failures to enumerate valid email addresses and temporarily lock valid accounts. This issue is fixed in version 3.39.25.

Severity

5.3 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-13 12:18 UTC

CWE

CWE-204 - Observable Response Discrepancy

Assigner

GitHub_M

References

4 references

URL	Tags
https://github.com/Budibase/budibase/security/adv…	x_refsource_CONFIRM
https://github.com/Budibase/budibase/pull/19108	x_refsource_MISC
https://github.com/Budibase/budibase/commit/eaae8…	x_refsource_MISC
https://github.com/Budibase/budibase/releases/tag…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
Budibase	budibase	Affected: < 3.39.25

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-73306",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-13T12:18:33.414991Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-13T12:18:51.707Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-cr7p-cr3q-h5cm"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "budibase",
          "vendor": "Budibase",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.39.25"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Budibase is an open-source low-code platform. Prior to 3.39.25, POST /api/global/auth/:tenantId/login incremented the failure counter in packages/worker/src/api/controllers/global/auth.ts only for existing users, while packages/worker/src/middleware/emailLockout.ts returned X-Account-Locked and Retry-After only for locked identifiers. An unauthenticated attacker could compare the response after repeated failures to enumerate valid email addresses and temporarily lock valid accounts. This issue is fixed in version 3.39.25."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-204",
              "description": "CWE-204: Observable Response Discrepancy",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-12T18:56:08.322Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Budibase/budibase/security/advisories/GHSA-cr7p-cr3q-h5cm",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-cr7p-cr3q-h5cm"
        },
        {
          "name": "https://github.com/Budibase/budibase/pull/19108",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Budibase/budibase/pull/19108"
        },
        {
          "name": "https://github.com/Budibase/budibase/commit/eaae816ab81615c07eb10e4619af078d00e2a706",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Budibase/budibase/commit/eaae816ab81615c07eb10e4619af078d00e2a706"
        },
        {
          "name": "https://github.com/Budibase/budibase/releases/tag/3.39.25",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Budibase/budibase/releases/tag/3.39.25"
        }
      ],
      "source": {
        "advisory": "GHSA-cr7p-cr3q-h5cm",
        "discovery": "UNKNOWN"
      },
      "title": "Budibase: Account Enumeration via Login Lockout Response Differential"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-73306",
    "datePublished": "2026-08-12T18:56:08.322Z",
    "dateReserved": "2026-08-11T19:42:11.451Z",
    "dateUpdated": "2026-08-13T12:18:51.707Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.

Action not permitted

GHSA-CR7P-CR3Q-H5CM

Summary

Details

PoC

Impact

Recommended Fix

CVE-2026-73306 (GCVE-0-2026-73306)

Tags

Sightings

Nomenclature