CVE-2026-73306

The CVSS 5.3 rating for this authentication enumeration flaw in Budibase understates the actual risk in multi-tenant deployments. The core issue isn't simply that valid emails can be guessed — it's that two security mechanisms operated on logically different definitions of 'user,' creating an exploitable asymmetry: the auth controller only tracked failure counts for existing accounts, while the lockout middleware only enforced protections for already-locked identifiers. An attacker probing arbitrary emails faces zero lockout risk for non-existent accounts but triggers account denial for valid ones, enabling exhaustive enumeration of the entire user population without triggering any self-imposed limitations. This matters disproportionately in Budibase's multi-tenant context. Enumerating valid emails on a shared instance maps organizational hierarchies, identifies admin access to business-critical applications, and surfaces high-value targets across every organization hosted there. The enumerated data directly enables follow-on attacks: targeted phishing, credential stuffing, and the lockout DoS against each identified user — all without the attacker ever triggering their own lockout. To verify if you're vulnerable on a self-hosted Budibase instance: First, confirm your version via the /api/self/check endpoint — versions prior to 3.39.25 are affected. Second, test the enumeration oracle by submitting authentication attempts for known-invalid emails against the login endpoint; observe that no failure counter increments and no rate limiting applies, then repeat for a valid user account and observe that failure tracking and eventual lockout behavior differs. If you cannot upgrade immediately, consider upstream rate limiting at the API gateway or WAF layer that treats both valid and invalid usernames identically. The fix required coordinating those two previously-independent code paths. This pattern — enumeration oracle combined with lockout mechanism creating compound attacker advantage — has appeared in CVE after CVE. Each gets patched individually, but the architectural root cause persists: security features layered onto auth systems without a canonical identity reference shared across all components. That's what you should be auditing in your own auth implementations, not just whether a specific version is patched.

Reviewed through automated stages and approved by a human before publication.