GHSA-6VP2-6R7M-2JVX

Vulnerability from github – Published: 2026-05-19 16:30 – Updated: 2026-05-19 16:30
VLAI
Summary
Budibase: Missing Cache Invalidation on Public API Role Unassignment Allows Revoked Users to Retain Privileges for Up to 1 Hour
Details

Summary

The public API role unassignment endpoint (POST /api/public/v1/roles/unassign) updates user documents in CouchDB but does not invalidate the corresponding Redis user cache entries. Because the authentication middleware resolves user identity and permissions from this cache (TTL: 3600 seconds), a user whose admin, builder, or app-level roles have been revoked via the public API retains those privileges for up to 1 hour.

Details

The root cause is an inconsistency between the UserDB.save() and UserDB.bulkUpdate() code paths.

Vulnerable pathpackages/pro/src/sdk/publicApi/roles.ts:49-75:

export async function unAssign(userIds: string[], opts: AssignmentOpts) {
  // ... modifies user objects: deletes roles, admin, builder ...
  await userDB.bulkUpdate(users)  // line 74
}

bulkUpdate delegates to bulkUpdateGlobalUsers() at packages/backend-core/src/users/users.ts:82-85:

export async function bulkUpdateGlobalUsers(users: User[]) {
  const db = getGlobalDB()
  return (await db.bulkDocs(users)) as BulkDocsResponse
}

This writes directly to CouchDB with no cache invalidation.

Correct pathpackages/backend-core/src/users/db.ts:355 (used by admin UI):

await cache.user.invalidateUser(response.id)

Cache configurationpackages/backend-core/src/cache/user.ts:11:

const EXPIRY_SECONDS = 3600  // 1 hour TTL

Authentication middlewarepackages/backend-core/src/middleware/authenticated.ts:153-160:

user = await getUser({
  userId,
  tenantId: session.tenantId,
  email: session.email,
})

getUser() reads from Redis cache first; it only falls back to CouchDB on cache miss. After unAssign updates CouchDB without invalidating Redis, every authenticated request continues to use the stale cached user object with the old (revoked) privileges.

Notably, other bulk operations in the codebase handle this correctly — groups.addUsers() and groups.removeUsers() in packages/pro/src/sdk/groups/groups.ts both loop through affected users and call cache.user.invalidateUser() after bulkUpdateGlobalUsers(). The public API roles path was missed.

PoC

# Prerequisites: Enterprise license, admin API key, a second user with admin role

# Step 1: Confirm user has admin access
curl -s -X GET http://localhost:10000/api/global/roles \
  -H 'Cookie: budibase:auth=<target-user-session>' \
  -H 'x-budibase-app-id: app_xyz'
# Returns 200 with roles list

# Step 2: Revoke admin role via public API
curl -s -X POST http://localhost:10000/api/public/v1/roles/unassign \
  -H 'x-budibase-api-key: <admin-api-key>' \
  -H 'Content-Type: application/json' \
  -d '{"userIds": ["<target-user-id>"], "admin": true}'
# Returns 200 — role removed from CouchDB

# Step 3: Verify DB was updated (admin field removed)
# (check CouchDB directly - user document no longer has admin: {global: true})

# Step 4: Immediately retry admin endpoint as revoked user
curl -s -X GET http://localhost:10000/api/global/roles \
  -H 'Cookie: budibase:auth=<target-user-session>' \
  -H 'x-budibase-app-id: app_xyz'
# STILL returns 200 — stale cache serves old admin privileges

# Step 5: Wait for cache expiry (up to 3600 seconds) and retry
# After cache expires, the request correctly returns 403

Impact

A user whose admin, builder, or app-level roles have been revoked via the public API retains full access to those privileges for up to 1 hour. This is particularly concerning in automated offboarding scenarios where HR/IT systems use the public API to revoke access for terminated employees — the terminated user retains admin/builder access to all applications and data during the cache window.

The impact is bounded by: - Requires enterprise license (expanded public API feature) - Maximum 1-hour window before cache expires - Only affects the public API revocation path; revocations via the admin UI (UserDB.save()) invalidate cache correctly - The assign direction has the inverse issue (newly granted roles are delayed) but this is less security-critical

Recommended Fix

Add cache invalidation to bulkUpdateGlobalUsers or to the callers that need it. The most targeted fix is in the unAssign function:

// packages/pro/src/sdk/publicApi/roles.ts
import { cache } from "@budibase/backend-core"

export async function unAssign(userIds: string[], opts: AssignmentOpts) {
  // ... existing role removal logic ...
  await userDB.bulkUpdate(users)

  // Invalidate cache for all affected users
  await Promise.all(
    users.map(user => cache.user.invalidateUser(user._id!))
  )
}

Alternatively, fix it at the bulkUpdate level to prevent future callers from having the same gap:

// packages/backend-core/src/users/db.ts
static async bulkUpdate(users: User[]) {
  const result = await usersCore.bulkUpdateGlobalUsers(users)
  await Promise.all(
    users.map(user => cache.user.invalidateUser(user._id!))
  )
  return result
}

The same fix should also be applied to the assign function in the same file.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/backend-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.38.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46424"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T16:30:38Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe public API role unassignment endpoint (`POST /api/public/v1/roles/unassign`) updates user documents in CouchDB but does not invalidate the corresponding Redis user cache entries. Because the authentication middleware resolves user identity and permissions from this cache (TTL: 3600 seconds), a user whose admin, builder, or app-level roles have been revoked via the public API retains those privileges for up to 1 hour.\n\n## Details\n\nThe root cause is an inconsistency between the `UserDB.save()` and `UserDB.bulkUpdate()` code paths.\n\n**Vulnerable path** \u2014 `packages/pro/src/sdk/publicApi/roles.ts:49-75`:\n```typescript\nexport async function unAssign(userIds: string[], opts: AssignmentOpts) {\n  // ... modifies user objects: deletes roles, admin, builder ...\n  await userDB.bulkUpdate(users)  // line 74\n}\n```\n\n`bulkUpdate` delegates to `bulkUpdateGlobalUsers()` at `packages/backend-core/src/users/users.ts:82-85`:\n```typescript\nexport async function bulkUpdateGlobalUsers(users: User[]) {\n  const db = getGlobalDB()\n  return (await db.bulkDocs(users)) as BulkDocsResponse\n}\n```\n\nThis writes directly to CouchDB with **no cache invalidation**.\n\n**Correct path** \u2014 `packages/backend-core/src/users/db.ts:355` (used by admin UI):\n```typescript\nawait cache.user.invalidateUser(response.id)\n```\n\n**Cache configuration** \u2014 `packages/backend-core/src/cache/user.ts:11`:\n```typescript\nconst EXPIRY_SECONDS = 3600  // 1 hour TTL\n```\n\n**Authentication middleware** \u2014 `packages/backend-core/src/middleware/authenticated.ts:153-160`:\n```typescript\nuser = await getUser({\n  userId,\n  tenantId: session.tenantId,\n  email: session.email,\n})\n```\n\n`getUser()` reads from Redis cache first; it only falls back to CouchDB on cache miss. After `unAssign` updates CouchDB without invalidating Redis, every authenticated request continues to use the stale cached user object with the old (revoked) privileges.\n\nNotably, other bulk operations in the codebase handle this correctly \u2014 `groups.addUsers()` and `groups.removeUsers()` in `packages/pro/src/sdk/groups/groups.ts` both loop through affected users and call `cache.user.invalidateUser()` after `bulkUpdateGlobalUsers()`. The public API roles path was missed.\n\n## PoC\n\n```bash\n# Prerequisites: Enterprise license, admin API key, a second user with admin role\n\n# Step 1: Confirm user has admin access\ncurl -s -X GET http://localhost:10000/api/global/roles \\\n  -H \u0027Cookie: budibase:auth=\u003ctarget-user-session\u003e\u0027 \\\n  -H \u0027x-budibase-app-id: app_xyz\u0027\n# Returns 200 with roles list\n\n# Step 2: Revoke admin role via public API\ncurl -s -X POST http://localhost:10000/api/public/v1/roles/unassign \\\n  -H \u0027x-budibase-api-key: \u003cadmin-api-key\u003e\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"userIds\": [\"\u003ctarget-user-id\u003e\"], \"admin\": true}\u0027\n# Returns 200 \u2014 role removed from CouchDB\n\n# Step 3: Verify DB was updated (admin field removed)\n# (check CouchDB directly - user document no longer has admin: {global: true})\n\n# Step 4: Immediately retry admin endpoint as revoked user\ncurl -s -X GET http://localhost:10000/api/global/roles \\\n  -H \u0027Cookie: budibase:auth=\u003ctarget-user-session\u003e\u0027 \\\n  -H \u0027x-budibase-app-id: app_xyz\u0027\n# STILL returns 200 \u2014 stale cache serves old admin privileges\n\n# Step 5: Wait for cache expiry (up to 3600 seconds) and retry\n# After cache expires, the request correctly returns 403\n```\n\n## Impact\n\nA user whose admin, builder, or app-level roles have been revoked via the public API retains full access to those privileges for up to 1 hour. This is particularly concerning in automated offboarding scenarios where HR/IT systems use the public API to revoke access for terminated employees \u2014 the terminated user retains admin/builder access to all applications and data during the cache window.\n\nThe impact is bounded by:\n- Requires enterprise license (expanded public API feature)\n- Maximum 1-hour window before cache expires\n- Only affects the public API revocation path; revocations via the admin UI (`UserDB.save()`) invalidate cache correctly\n- The `assign` direction has the inverse issue (newly granted roles are delayed) but this is less security-critical\n\n## Recommended Fix\n\nAdd cache invalidation to `bulkUpdateGlobalUsers` or to the callers that need it. The most targeted fix is in the `unAssign` function:\n\n```typescript\n// packages/pro/src/sdk/publicApi/roles.ts\nimport { cache } from \"@budibase/backend-core\"\n\nexport async function unAssign(userIds: string[], opts: AssignmentOpts) {\n  // ... existing role removal logic ...\n  await userDB.bulkUpdate(users)\n  \n  // Invalidate cache for all affected users\n  await Promise.all(\n    users.map(user =\u003e cache.user.invalidateUser(user._id!))\n  )\n}\n```\n\nAlternatively, fix it at the `bulkUpdate` level to prevent future callers from having the same gap:\n\n```typescript\n// packages/backend-core/src/users/db.ts\nstatic async bulkUpdate(users: User[]) {\n  const result = await usersCore.bulkUpdateGlobalUsers(users)\n  await Promise.all(\n    users.map(user =\u003e cache.user.invalidateUser(user._id!))\n  )\n  return result\n}\n```\n\nThe same fix should also be applied to the `assign` function in the same file.",
  "id": "GHSA-6vp2-6r7m-2jvx",
  "modified": "2026-05-19T16:30:38Z",
  "published": "2026-05-19T16:30:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-6vp2-6r7m-2jvx"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.38.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Budibase: Missing Cache Invalidation on Public API Role Unassignment Allows Revoked Users to Retain Privileges for Up to 1 Hour"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…