GHSA-J9FC-W3MR-X6MV高危已审查

Budibase: Privilege escalation via public role assignment API missing app-level authorization

OSV 1.4.0 · github-reviewed · 修改于 2026-08-13 02:57

发布时间

2026-07-25 05:12

GitHub 审查时间

2026-07-25 05:12

NVD 发布时间

—

源文件

advisories/github-reviewed/2026/07/GHSA-j9fc-w3mr-x6mv/GHSA-j9fc-w3mr-x6mv.json

公告说明

Summary

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.

Details

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 / 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 userIds is an arbitrary list (bulkGet). The only gate is the isExpandedPublicApiEnabled() license check.

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.

Attacker is an app-scoped builder of 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.
Attacker is now a builder of appB (and, via the role vector, can set any data-role such as ADMIN in any app).

Security boundary crossed:

Before: builder of appA only.
After: builder of 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.
Why disallowed: the per-app builder model is meant to isolate builders to their assigned apps; a builder of one app must not gain authority over apps they were never granted.

Budibase version: 3.39.19, commit 03fbabae4
Deployment: Business/Enterprise license required (isExpandedPublicApiEnabled)
Attacker role: app-scoped builder (user.builder.apps=[appA]), not global builder/admin
Mock services: none needed for the unit-level proof; HTTP PoC script provided for a licensed lab

Steps (unit-level proof, no license needed — verbatim auth-gate + SDK logic):

Run the verification harness:

cd D:/CVE-Hunting/budibase-audit-output/lab
node harness/verify-privesc-authz.cjs

Observed result (evidence: 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/lab-privesc-authz.log
poc/verify-privesc-authz.cjs, poc/privesc-roles-assign.sh

Runtime 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:

escalate to builder of every other app in the tenant (cross-app/workspace isolation bypass);
read and modify all rows in those apps;
read those apps' datasource configurations and exfiltrate stored datasource credentials;
edit automations in those apps, including server-side execution steps;
assign arbitrary data-plane roles (e.g. 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.

受影响的软件包

npm

@budibase/server

ECOSYSTEM

引入0最后受影响3.38.1

标识信息

别名 / CVE

CVE-2026-73305

CWE

CWE-269CWE-862CWE-863

软件生态

npm

扩展资料

暂无扩展资料。

CVSS 评分

CVSS_V3

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

原始 OSV JSON

{
  "id": "GHSA-j9fc-w3mr-x6mv",
  "aliases": [
    "CVE-2026-73305"
  ],
  "details": "### Summary\n\nBudibase `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.\n\nThis 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.\n\n### Details\n\nThe issue is caused by authorization being implemented as a **flag-level allowlist** (`admin`/`builder`) instead of validating the *scope* the caller is granting.\n\nRelevant code paths:\n\n- `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.\n- `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.\n- `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 `userIds` is an arbitrary list (`bulkGet`). The only gate is the `isExpandedPublicApiEnabled()` license check.\n- `packages/server/src/api/routes/public/index.ts` — `applyAdminRoutes(roleEndpoints)` attaches **only** `middleware.builderOrAdmin` (no `publicApi`, no `authorized(PermissionType.USER, …)`).\n- `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.\n- `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.\n- `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.\n\nAttack flow:\n\n1. Attacker is an app-scoped builder of `appA` only (no global builder/admin).\n2. `POST /api/global/self/api_key` (worker) — passes `builderOnly` via `hasBuilderPermissions` → attacker obtains a public API key.\n3. `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`.\n4. Attacker is now a builder of `appB` (and, via the `role` vector, can set any data-role such as `ADMIN` in any app).\n\nSecurity boundary crossed:\n\n- **Before:** builder of `appA` only.\n- **After:** builder of `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.\n- **Why disallowed:** the per-app builder model is meant to isolate builders to their assigned apps; a builder of one app must not gain authority over apps they were never granted.\n\n### PoC\n\nEnvironment:\n\n- Budibase version: `3.39.19`, commit `03fbabae4`\n- Deployment: Business/Enterprise license required (`isExpandedPublicApiEnabled`)\n- Attacker role: app-scoped builder (`user.builder.apps=[appA]`), not global builder/admin\n- Mock services: none needed for the unit-level proof; HTTP PoC script provided for a licensed lab\n\nSteps (unit-level proof, no license needed — verbatim auth-gate + SDK logic):\n\n1. Run the verification harness:\n\n```bash\ncd D:/CVE-Hunting/budibase-audit-output/lab\nnode harness/verify-privesc-authz.cjs\n```\n\n2. Observed result (evidence: `evidence/lab-privesc-authz.log`):\n\n```text\n[PASS-VALIDATION] appBuilder:{appId:APP_B}          -> NOT rejected\n[PASS-VALIDATION] role:{appId:APP_B, roleId:'ADMIN'}-> NOT rejected\n[BLOCKED 403]      builder:true (global)            -> Only global builders or admins ...\n[BLOCKED 403]      admin:true (global)              -> Only global admins ...\nafter : builder={\"apps\":[\"app_A...\",\"app_B...\"]} roles={\"app_B...\":\"ADMIN\"}\nisBuilder(attacker, APP_B) now = true   <-- escalated to builder of APP_B\n```\n\nSteps (HTTP PoC for a licensed lab — `poc/privesc-roles-assign.sh`):\n\n```bash\n# 1) self-issue API key\ncurl -X POST http://localhost:10000/api/global/self/api_key -H \"Cookie: <attacker session>\" -d '{}'\n# 2) escalate: grant self builder of appB\ncurl -X POST http://localhost:10000/api/public/v1/roles/assign \\\n  -H \"x-budibase-api-key: <KEY>\" -H \"x-budibase-app-id: <appA prod id>\" \\\n  -H \"content-type: application/json\" \\\n  -d '{\"userIds\":[\"<self global id>\"],\"appBuilder\":{\"appId\":\"<appB>\"}}'\n```\n\n3. Expected result:\n\n```text\nThe request should be rejected (403) — an app-scoped builder must not be able to grant\nitself builder/role access to an app it does not control. Instead it returns 200 and the\ngrant is applied.\n```\n\nEvidence files:\n\n- `evidence/lab-privesc-authz.log`\n- `poc/verify-privesc-authz.cjs`, `poc/privesc-roles-assign.sh`\n\n**Runtime 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.\n\n### Source PoC\n\n[Budibase-GHSA-Reports.zip](https://github.com/user-attachments/files/29161435/Budibase-GHSA-Reports.zip)\n\n### Impact\n\nAn attacker holding an **app-scoped builder** role on a single app in a licensed (Business/Enterprise) tenant can:\n\n* escalate to builder of **every other app** in the tenant (cross-app/workspace isolation bypass);\n* read and modify all rows in those apps;\n* read those apps' datasource configurations and **exfiltrate stored datasource credentials**;\n* edit automations in those apps, including server-side execution steps;\n* assign arbitrary data-plane roles (e.g. `ADMIN`) in any app to any user, including themselves.\n\nIt 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.",
  "summary": " Budibase: Privilege escalation via public role assignment API missing app-level authorization",
  "affected": [
    {
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.38.1"
            }
          ]
        }
      ],
      "package": {
        "name": "@budibase/server",
        "ecosystem": "npm"
      }
    }
  ],
  "modified": "2026-08-12T18:57:18Z",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "published": "2026-07-24T21:12:40Z",
  "references": [
    {
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-j9fc-w3mr-x6mv",
      "type": "WEB"
    },
    {
      "url": "https://github.com/Budibase/budibase",
      "type": "PACKAGE"
    },
    {
      "url": "https://github.com/Budibase/budibase/releases/tag/3.40.0",
      "type": "WEB"
    }
  ],
  "schema_version": "1.4.0",
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-862",
      "CWE-863"
    ],
    "severity": "HIGH",
    "github_reviewed": true,
    "nvd_published_at": null,
    "github_reviewed_at": "2026-07-24T21:12:40Z"
  }
}