Budibase EUVD-2026-32597

The role revocation must be performed via the public API endpoint POST /api/public/v1/roles/unassign - this endpoint is available only on enterprise-licensed Budibase deployments; revocations via the Budibase admin UI are NOT vulnerable. The targeted user must have an active authenticated session (valid budibase:auth session cookie) at the time of revocation, and the Redis cache entry for that user must not have naturally expired (TTL: up to 3600 seconds). Per CVSS PR:L, the exploiting party (the user retaining stale privileges) holds low-privilege authenticated credentials. Exploitation is bounded to a maximum 1-hour window after the revocation call. There is no requirement for any special network position beyond authenticated access to the Budibase instance. Revocations of the assign direction (newly granted roles being delayed) exist but are noted by the vendor as less security-critical.

The CVSS 3.1 score of 4.2 (Medium) with vector AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N reflects the real-world conditions accurately: network-accessible but requiring high attack complexity, low privileges (an authenticated session for the targeted user), and limited scope impacts. AC:H is justified by the multi-step prerequisite chain - an enterprise license must be active, the revocation must occur via the public API (not the admin UI), and the targeted user must hold an unexpired Redis cache entry. EPSS score was not provided in the input data and cannot be assessed quantitatively. No CISA KEV listing exists, so active exploitation is not confirmed; however, a functional PoC is embedded in the GHSA advisory, which meaningfully lowers the exploitation barrier compared to theoretical vulnerabilities. The most acute real-world risk is in automated offboarding pipelines where HR or IT systems use the public API to revoke access for terminated employees - in that scenario, the window of retained admin access is predictable and reproducible. The 1-hour bounded window and enterprise-only scope limit blast radius, making this a medium-priority issue for most organizations unless automated offboarding via the public API is in active use.

An IT administrator triggers an automated offboarding workflow that calls POST /api/public/v1/roles/unassign to remove admin privileges from a terminated employee's account; the CouchDB user document is updated immediately and the API returns HTTP 200. The terminated employee, who still holds a valid session cookie, continues sending authenticated requests to Budibase - the authentication middleware reads the stale Redis cache entry (not yet expired after 3600 seconds) and continues granting admin-level access to all applications and data. A PoC demonstrating this exact scenario is included in the GHSA-6vp2-6r7m-2jvx advisory.