Budibase Unauthenticated User Info Disclosure via Public Tenant Lookup Endpoint (CVE-2026-73406)

Vulnerability Overview Title: Unauthenticated user information disclosure via public tenant user lookup endpoint Description: Summary: Budibase’s Worker service exposes a public, unauthenticated API endpoint ( ) that returns sensitive user information, including , , , and . This endpoint is registered in the list and includes a comment indicating it should be an internal API. Any unauthenticated user can enumerate sensitive user or tenant information, enabling targeted attacks against multi-tenant deployments. Details: - Public Endpoint Registration: Lines 56–59 in . - Route Registration: Line 139 in . - Handler Implementation: Lines 548–562 in . - Lookup Function: Lines 48–53 in , which queries the CouchDB view and returns complete platform user data. Impact CVSS v3 Base Metrics: - Attack Vector: Network - Attack Complexity: Low - Privileges Required: None - User Interaction: None - Scope: Unchanged - Confidentiality: High - Integrity: None - Availability: None CVE ID: CVE-2026-73406 Weakness: CWE-200 Impact: This is a CWE-200 vulnerability: exposure of sensitive information to unauthorized parties. Affected Users: All Budibase deployments, whether self-hosted or cloud-based. The impact is highest in multi-tenant (cloud) deployments, where the tenant ID serves as a security boundary; user enumeration can lead to targeted attacks against specific tenants. Unauthenticated attackers can: 1. Enumerate all user accounts by testing known or guessed email addresses. 2. Extract known users’ tenant IDs, enabling targeted cross-tenant attacks. 3. Extract user IDs ( ) for use in other API calls or attacks. 4. Extract SSO identifiers ( ), which may be linked to external identity providers (Google, OIDC). 5. Confirm user existence through different HTTP responses (200 vs. 400). 6. Collect CouchDB revision tokens ( ), which may assist in CouchDB-level attacks. Remediation 1. Remove the endpoint from and move it to internal-only routes, as suggested by the comment on line 56. 2. If the endpoint must remain accessible, add authentication and authorization—at minimum, requiring a or role. 3. Limit returned fields to only those actually required by consumers (e.g., and other non-sensitive fields; exclude sensitive fields like email and ssoId). 4. Return a generic 404 for both “not found” and “access denied” responses to prevent user enumeration. 5. Add rate limiting to prevent automated large-scale enumeration. 6. Regression test: Add a test verifying that returns a 403 status code when unauthenticated. POC Code Static Verification 1. Observe lines 56–59 in : the endpoint is listed in with a comment stating it should be an internal API. 2. Trace the handler in lines 548–562 of : there is no authentication check, and it returns (the complete object). 3. Trace the middleware chain: all middleware sets . 4. Confirm there is no field filtering, sanitization, or authorization between the request and response. Dynamic Verification (requires a running Budibase instance with at least one user) Negative Cases Requesting a non-existent user returns HTTP 400 with the message "No tenant user found.", while existing users return HTTP 200 with full data. The differing status codes confirm user existence, enabling enumeration.

Goal Reached Thanks to every supporter — we hit 100%!

Budibase Unauthenticated User Info Disclosure via Public Tenant Lookup Endpoint (CVE-2026-73406)

More from this source