Budibase: Account Enumeration via Login Lockout Response Differential — @budibase / server
Observable Response DiscrepancySummary
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):
lockoutmiddleware →getUserByEmailreturns user →isLockedreturns true → 403 +X-Account-Locked: 1+Retry-After: 900+ "Account temporarily locked"
Execution flow for non-existing users (any number of attempts):
lockoutmiddleware →getUserByEmailreturns null →dbUser && isLockedis false → passes through- Login handler → passport fails →
if (dbUser)is false →onFailed()never called → lock never set - 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":"[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.
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-Lockedheader. - 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.
| Software | From | Fixed in |
|---|---|---|
@budibase / server
|
- | 3.38.1.x |
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.