The vulnerability is an account enumeration issue in Budibase's login functionality, identified as GHSA-cr7p-cr3q-h5cm. The root cause is a difference in how login attempts are handled for existing versus non-existing users. The analysis of the provided patch commit eaae816ab81615c07eb10e4619af078d00e2a706 confirms this.
Two key functions were involved:
-
login in packages/worker/src/api/controllers/global/auth.ts: This function is responsible for handling the authentication logic. The vulnerable version only incremented the failed login attempt counter (onFailed(email)) for users that were found in the database. For non-existent users, the counter was never incremented, so they could never be locked out.
-
emailLockout middleware in packages/worker/src/middleware/emailLockout.ts: This middleware is designed to block login attempts for locked accounts. However, it only performed this check for users confirmed to exist in the database. This meant a non-existent user would never trigger the lockout response, even if the onFailed function were called for them.
An attacker could exploit this by sending multiple failed login attempts for a target email address. If the server's response changed after 5-6 attempts to an "Account temporarily locked" message (with specific headers like X-Account-Locked: 1), the attacker could confirm the email address is registered. If the response remained a generic "Unauthorized" message, the email is not registered. The patch rectifies this by removing the user existence checks in both functions, ensuring the lockout logic is applied consistently to all emails, thereby eliminating the response discrepancy.