App-scoped builders can grant builder access to unrelated apps through public user update API

Summary

Budibase 3.39.26 allows an authenticated app-scoped builder for one app to grant builder access to another unrelated app through the public user create/update API.

The vulnerable path accepts and persists app-scoped builder role data such as builder.apps without validating that the caller is allowed to assign builder access for those target apps. As a result, a builder for App A can update a user, including themselves, and add builder access for App B, even though they are not a global admin, not a global builder, and not a builder for App B.

This creates a cross-app privilege escalation within the tenant.

Affected version

• Product: Budibase
• Version: 3.39.26
• Commit: f6e5b2fb9294bf754e0f7b999868643e116d850b

Affected endpoints

• PUT /api/public/v1/users/:userId
• POST /api/public/v1/users

Affected code

• packages/server/src/api/controllers/public/users.ts

The vulnerable create/update path calls createUpdateResponse(), which validates global role updates but does not validate app-scoped role assignments such as builder.apps.

Attacker model

The attacker is:

• authenticated;
• an app builder for App A;
• allowed to use the public API / API key for App A;
• not a global admin;
• not a global builder;
• not a builder for App B.

The target App B exists in the same tenant.

Root cause

The public user create/update path validates global role changes but does not validate app-scoped builder assignments.

Specifically, createUpdateResponse() calls validateGlobalRoleUpdate() with only global admin / builder deltas. App-scoped role fields such as builder.apps are not passed into that validation path.

When expanded public API behavior is enabled, sdk.publicApi.users.roleCheck() does not strip or reject builder.apps, and the worker-side user save accepts and persists it.

This allows an app-scoped builder for one app to assign builder access for another app they do not control.

Proof of concept

Given:

• App A: attacker is a builder.
• App B: attacker is not a builder.
• Target user: a normal user or the attacker’s own user account.

Send the following request as the App A builder:

PUT /api/public/v1/users/{targetUserId}
x-budibase-api-key: <attacker_public_api_key>
x-budibase-app-id: <app_a_id>
Cookie: <attacker_app_builder_session>
Content-Type: application/json

{
  "_id": "{targetUserId}",
  "email": "target@example.com",
  "roles": {},
  "builder": {
    "apps": ["app_target_b"]
  }
}

Observed result:

{
  "builder": {
    "apps": ["app_target_b"]
  }
}

The target user is updated with builder access to App B, even though the caller only has builder access to App A.

Negative control

A basic non-builder user sending the same request receives 403.

Additionally, before the public user update, the attacker or target user cannot perform builder-only actions against App B. After the update persists builder.apps: ["app_target_b"], the user can perform builder-only actions against App B.

Runtime evidence

A focused Jest proof-of-concept test was added temporarily and executed against Budibase 3.39.26.

Command:

bash -lc 'eval "$(fnm env --use-on-cd)"; fnm use 22.19.0; yarn --cwd packages/server test users-role-scope.poc.spec.ts'

Observed behavior:

• Basic user: 403
• App builder for App A: 200
• Response persisted builder.apps containing the unrelated target App B ID.

The test was removed after validation.

Impact

An app-scoped builder can grant a user, including themselves, builder access to an app they do not control.

This gives unauthorized builder-level capability over the target app’s design and data plane. Depending on the target app configuration, this may allow the attacker to inspect or modify app structure, screens, automations, queries, datasource-backed actions, and other builder-only resources.

This is a cross-app privilege escalation within the same Budibase tenant.

Suggested fix

Reject or strip app-scoped role fields such as builder.apps from public user create/update requests unless the caller has permission to assign builder access for every target app ID.

The authorization check should verify that the caller is allowed to manage builder access for the specific app IDs being assigned, not only whether the caller has builder access to the app associated with the API key/request context.

It would also be safer to maintain an explicit allowlist of user fields accepted by the public API instead of allowing role-bearing internal fields to pass through to the worker-side user save path.