CVE-2026-48150 - Budibase workspace builder to global admin escalation
Budibase before 3.39.0 allowed a workspace-scoped builder to use
/api/public/v1/roles/assign to set builder.global=true or
admin.global=true on chosen users. Middleware admitted builders for the app
identified in x-budibase-app-id, while the controller passed role assignment
properties through to the SDK without filtering out global role fields.
This is a tenant-wide privilege-escalation path in Enterprise deployments that share app-building duties across teams.
When to use it
Use this recipe when a repository deploys Budibase Enterprise-style workspaces, public API role assignment, or low-code builders that should remain scoped to a workspace/app. It is designed for source-code/deployment remediation, RBAC scope-boundary review, request-body field filtering, audit-log review, and evidence that workspace builders cannot assign global roles.
Inputs
- Budibase server version, npm/pnpm/yarn lock state, image/chart/manifest pins, public API settings, role-assignment endpoints, and generated dependency or SBOM reports.
- Source/config paths for
/api/public/v1/roles/assign,x-budibase-app-id, builder/admin middleware, SDK role assignment, request validation, audit logs, and tests. - Regression fixtures for workspace builders, global admins, forged global role fields, cross-app IDs, public API keys, and expected denial/audit behavior.
- Boundary evidence: workspace owners, global admins, API keys, role-change logs, session/key rotation needs, rollout owner, and account-review owner.
Affected versions
- Vulnerable:
@budibase/server <3.39.0 - Fixed:
@budibase/server 3.39.0+ - Affected surface: public API role-assignment flows in Enterprise-style deployments with builder users
Indicator-of-exposure
- The repository deploys Budibase server versions before
3.39.0. - Enterprise or public API features expose role assignment endpoints.
- Workspace-scoped builders or automation keys can call
/api/public/v1/roles/assign.
Quick checks:
rg -n "roles/assign|builderOrAdmin|x-budibase-app-id|builder\\.global|admin\\.global|EXPANDED_PUBLIC_API" .
npm ls @budibase/server
pnpm why @budibase/server
Windows:
rg -n "roles/assign|builderOrAdmin|x-budibase-app-id|builder\\.global|admin\\.global|EXPANDED_PUBLIC_API" .
npm ls @budibase/server
pnpm why @budibase/server
Remediation strategy
- Upgrade Budibase to
3.39.0+. - Enforce authorization that distinguishes workspace-scoped builders from global builders/admins on every role-assignment path.
- Constrain request-body fields so app-scoped callers cannot set global role attributes even if middleware fails.
- Review audit logs for unexpected role promotions and rotate API keys if lower-privilege builders had public API access.
The prompt
Model context: this prompt was generated by GPT 5.5 Extra High reasoning.
You are remediating CVE-2026-48150 / GHSA-6xp4-cf37-ppjh in Budibase.
Workspace-scoped builders can escalate to global builder/admin through the
public role-assignment API. Produce exactly one output:
- A reviewer-ready PR/change request that upgrades Budibase, hardens role
assignment authorization, adds regression tests, and documents audit actions,
or
- TRIAGE.md if this repository does not control an affected Budibase server.
## Rules
- Scope only CVE-2026-48150 and directly related role-assignment paths.
- Treat user ids, API keys, role data, and audit logs as sensitive.
- Do not promote test users to global roles in shared environments.
- Do not remove legitimate admin APIs as a shortcut if scoped authorization can
be fixed safely.
- Do not auto-merge.
## Steps
1. Inventory every `@budibase/server` dependency, image, chart, and deployment
artifact controlled by this repository.
2. Determine whether public role-assignment APIs are enabled and which users or
keys can reach them.
3. Inspect authorization and controller layers for app-scoped builder access
and unfiltered global role fields.
4. If this repository does not control an affected Budibase server, stop with
`TRIAGE.md` naming the owner and required fixed version `3.39.0+`.
5. Upgrade to `3.39.0+` and refresh locks, images, SBOMs, and deployment
artifacts.
6. Enforce fail-closed authorization so workspace-scoped builders cannot assign
tenant-global roles.
7. Add request validation or controller-side allow-lists so untrusted request
bodies cannot set `builder.global` or `admin.global`.
8. Add regression tests for app-scoped builders, global builders, and admins,
proving only the intended principals can assign global roles.
9. Add a PR body section named `CVE-2026-48150 operator actions` covering:
- versions before and after;
- whether the public API and enterprise features were enabled;
- which users or API keys may need review or rotation;
- which audit logs to inspect for historical role escalation;
- validation that passed.
10. Run available validation: dependency install, tests, build, image build,
deployment render, and security scans.
11. Use PR title:
`fix(sec): remediate CVE-2026-48150 in Budibase role assignment`.
## Stop conditions
- No affected Budibase server is controlled by this repository.
- Validation would require assigning global roles in shared environments.
- Product requirements intentionally allow workspace builders to manage tenant
global roles; document the risk and stop for review.
- Validation fails for unrelated pre-existing reasons; document those failures.
Output contract
- A reviewer-ready PR or change request that upgrades Budibase, filters global role fields from workspace-scoped callers, adds cross-scope authorization tests, and documents account/audit review.
- Or a
TRIAGE.mdfile that lists inspected packages/images/routes, owner, observed version, role-assignment boundary, required fix, and residual risk. - The output must include exact validation commands and must not promote real users, expose API keys, or weaken global admin protections.
Verification - what the reviewer looks for
- No controlled Budibase deployment resolves
<3.39.0. - App-scoped builders cannot assign tenant-global roles.
- Regression tests cover builder, global builder, and admin permutations.
- Audit and key-review follow-up is documented if exposure existed.
Watch for
- Middleware fixes without controller-side field filtering.
- Rotating the package while old API keys with broad access remain active.
- Assuming only self-promotion matters when the endpoint can also promote other users.
Related recipes
- Source code authz tenant boundary audit
- Source code secrets and data exposure audit
- OWASP Top 10 2026 audit
- NIST SSDF repository evidence check