GHSA-6xp4-cf37-ppjh: Budibase: Workspace-scoped builder escalates to global admin via /api/public/v1/roles/assign
Summary`/api/public/v1/roles/assign` is guarded by the `builderOrAdmin` middleware, which passes any user who is a builder for the app id in the `x-budibase-app-id` header. That check admits both global builders and workspace-scoped builders (`builder.apps` set but `builder.global` unset). The controller then spreads the request body into the SDK call, and the SDK grants `builder.global=true` or `admin.global=true` on whichever user ids the caller supplies. Bob, a workspace-scoped builder with an API key, promotes himself or any other user to global admin with one POST. The whole flow is tenant-wide privilege escalation from an app-level role, available to anyone with an Enterprise license that unlocks the `EXPANDED_PUBLIC_API` feature.DetailsController (`packages/server/src/api/controllers/public/roles.ts:13-17`):Nothing filters `assignmentProps`. The request body's `builder` and `admin` keys flow directly into the SDK.SDK (`packages/pro/src/sdk/publicApi/roles.ts:17-47`):No check that the caller already holds the privilege they are granting. `user.builder` is overwritten unconditionally, which also strips any existing `builder.apps` scope from the target.Route guard (`packages/backend-core/src/middleware/builderOrAdmin.ts:6-20`):`isBuilder(user, workspaceId)` returns true for any user whose `builder.apps` array contains the workspace id, even when `builder.global` is unset. The endpoint therefore trusts an app-level builder with a global-scope grant.Proof of ConceptTested on Budibase 3.35.8 (master at f960e361). The public API license gate at `roles.ts:18` was disabled in the test bundle so the underlying privilege-escalation could be reproduced end-to-end; on a licensed Enterprise tenant the gate passes and the same requests land.Step 1: the admin creates two users. Alice is a workspace-scoped builder on an app (`builder.apps: [app_...]`, `builder.global` unset, `admin.global` unset). Victim is a BASIC user.Step 2: Alice calls `GET /api/global/self/api_key` to mint an API key tied to her identity:Step 3: Alice calls `/api/public/v1/roles/assign` with the victim's id and `builder: true`. She scopes the request to her own app via `x-budibase-app-id` so `builderOrAdmin` passes:Admin verifies:Step 4: Alice follows up with `"admin": true` and can target her own id:Alice is now a global admin of the tenant. She kept `builder.apps` because the SDK only overwrites the keys it was asked to set; `admin: true` writes `admin = { global: true }` without touching `builder`.ImpactEvery workspace-scoped builder of any app in the tenant is one request away from global admin. Global admin grants unrestricted access to the tenant: every app in every workspace, every user, every datasource credential, every automation, every SCIM / OIDC / audit-log config. The mass-assignment also strips scoping from the target's existing role, so downgrading a legitimate global builder to an app-scoped builder fails: a later call reinstates `global: true`.A tenant that shares app-building duties across teams (the common Enterprise pattern) cannot hold the per-app boundary with the current middleware. This matches GHSA-2g39-332f-68p9 (Critical Privilege Escalation & IDOR via Missing RBAC) in shape and impact.Recommended FixEnforce the caller's privilege in the SDK, matching the grant they want to make:Alternative, equally valid: tighten `builderOrAdmin` so that endpoints which can set global-scope properties require `isGlobalBuilder` or `isAdmin`. That fixes this endpoint and any future endpoint that shares the middleware.Whichever fix lands, also strip `builder` and `admin` from `assignmentProps` at the controller boundary (`packages/server/src/api/controllers/public/roles.ts:14`) unless the caller has `admin.global=true`. Defense-in-depth against a future SDK regression.*Found by [aisafe.io](https://aisafe.io)*
CVSS v3.1: 9