| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| @budibase/server | ≤ 3.38.1 |
Budibase 3.39.19 (commit 03fbabae4) is affected by a privilege-escalation / missing-authorization flaw in the public role-assignment API. An app-scoped builder (a user who builds only specific apps — user.builder.apps = [appA], not a global builder or admin) can grant themselves builder access to ANY other app in the tenant, or assign themselves/any user an arbitrary data-plane role (e.g. ADMIN) in any app, by calling POST /api/public/v1/roles/assign. The endpoint only authorizes the two global flags (admin, builder); the per-app appBuilder and role:{appId,roleId} grant vectors are passed to the backend without any authorization check that the caller controls the target app. Reproduced in a local authorized lab using the verbatim authorization-gate and SDK logic.
This is an incomplete fix of the role-assignment hardening in commit d63d1d9054 ("Inline public user global role validation"), which only ever validated the global flags.
The issue is caused by authorization being implemented as a flag-level allowlist (admin/builder) instead of validating the scope the caller is granting.
Relevant code paths:
packages/server/src/api/controllers/public/globalRoleValidation.ts — validateGlobalRoleUpdate(ctx, roleUpdate) only checks roleUpdate.admin (requires isAdmin) and roleUpdate.builder (requires isGlobalBuilder). The GlobalRoleUpdate interface declares only { builder?, admin? }; appBuilder and role are not referenced.packages/server/src/api/controllers/public/roles.ts — assign() does const { userIds, ...assignmentProps } = ctx.request.body; validateGlobalRoleUpdate(ctx, assignmentProps); await sdk.publicApi.roles.assign(userIds, assignmentProps). The appBuilder/role props pass through unvalidated.packages/pro/src/sdk/publicApi/roles.ts — assign(): for opts.appBuilder it sets user.builder = { apps: existing.concat([getProdWorkspaceID(opts.appBuilder.appId)]) }; for opts.role it sets user.roles[getProdWorkspaceID(opts.role.appId)] = opts.role.roleId. No check that the caller builds the target app, and is an arbitrary list (). The only gate is the license check.これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャンuserIdsbulkGetisExpandedPublicApiEnabled()packages/server/src/api/routes/public/index.ts — applyAdminRoutes(roleEndpoints) attaches only middleware.builderOrAdmin (no publicApi, no authorized(PermissionType.USER, …)).packages/backend-core/src/middleware/builderOrAdmin.ts — with a workspaceId present, it only requires isBuilder(ctx.user, workspaceId). The attacker sets x-budibase-app-id to their own app (appA), so the gate passes.packages/backend-core/src/middleware/builderOnly.ts — on the worker, POST /api/global/self/api_key only requires hasBuilderPermissions(ctx.user), which is true for app-scoped builders, so the attacker can self-issue a public API key.packages/shared-core/src/sdk/documents/users.ts — isGlobalBuilder is false for app-scoped builders (so the global builder flag is correctly blocked), while isBuilder(user, appA) and hasBuilderPermissions(user) are true.Attack flow:
appA only (no global builder/admin).POST /api/global/self/api_key (worker) — passes builderOnly via hasBuilderPermissions → attacker obtains a public API key.POST /api/public/v1/roles/assign with header x-budibase-app-id: <appA prod id> and body {"userIds":["<self>"],"appBuilder":{"appId":"<appB>"}} — builderOrAdmin passes (isBuilder(user, appA)), validateGlobalRoleUpdate ignores appBuilder, the SDK pushes appB into user.builder.apps.appB (and, via the role vector, can set any data-role such as ADMIN in any app).Security boundary crossed:
appA only.appB (and any other app) → read/modify all rows, read datasource configs and exfiltrate stored datasource credentials, edit automations (including the bash/executeScript/executeQuery steps); plus arbitrary data-role assignment in any app.Environment:
3.39.19, commit 03fbabae4isExpandedPublicApiEnabled)user.builder.apps=[appA]), not global builder/adminSteps (unit-level proof, no license needed — verbatim auth-gate + SDK logic):
cd D:/CVE-Hunting/budibase-audit-output/lab
node harness/verify-privesc-authz.cjs
evidence/lab-privesc-authz.log):[PASS-VALIDATION] appBuilder:{appId:APP_B} -> NOT rejected
[PASS-VALIDATION] role:{appId:APP_B, roleId:'ADMIN'}-> NOT rejected
[BLOCKED 403] builder:true (global) -> Only global builders or admins ...
[BLOCKED 403] admin:true (global) -> Only global admins ...
after : builder={"apps":["app_A...","app_B..."]} roles={"app_B...":"ADMIN"}
isBuilder(attacker, APP_B) now = true <-- escalated to builder of APP_B
Steps (HTTP PoC for a licensed lab — poc/privesc-roles-assign.sh):
# 1) self-issue API key
curl -X POST http://localhost:10000/api/global/self/api_key -H "Cookie: <attacker session>" -d '{}'
# 2) escalate: grant self builder of appB
curl -X POST http://localhost:10000/api/public/v1/roles/assign \
-H "x-budibase-api-key: <KEY>" -H "x-budibase-app-id: <appA prod id>" \
-H "content-type: application/json" \
-d '{"userIds":["<self global id>"],"appBuilder":{"appId":"<appB>"}}'
The request should be rejected (403) — an app-scoped builder must not be able to grant
itself builder/role access to an app it does not control. Instead it returns 200 and the
grant is applied.
Evidence files:
evidence/lab-privesc-authz.logpoc/verify-privesc-authz.cjs, poc/privesc-roles-assign.shRuntime limitation: full HTTP end-to-end requires a Business/Enterprise license (isExpandedPublicApiEnabled); no license was cracked. The authorization defect is proven at unit level with the verbatim validation + SDK logic, and the route→validation→SDK call chain was independently verified by source review.
An attacker holding an app-scoped builder role on a single app in a licensed (Business/Enterprise) tenant can:
ADMIN) in any app to any user, including themselves.It does not grant the global admin/builder flags (those are validated), so it is not a direct global-admin takeover; but cross-app builder is effectively a tenant-wide app/data-plane compromise. No real secrets were accessed during testing; the lab used canary-only data.