Budibase Privilege Escalation via Unvalidated Role Assignment in Public API

Vulnerability Description

This is a broken access control and object-level authorization bypass in Budibase's public API role assignment endpoint. The root cause is insufficient input validation and overly permissive object spreading in the controller layer. The assignAppBuilder function accepts arbitrary properties from the request body (assignmentProps) and passes them directly to the SDK without filtering, allowing attackers to inject builder.global or admin.global properties. The middleware guard (builderOrAdmin) correctly identifies workspace-scoped builders but fails to enforce a scope boundary—it only verifies that the caller is some kind of builder, not that they have permission to grant global roles. This conflates app-level authorization with tenant-wide role assignment.

Proof-of-Concept Significance

This PoC demonstrates a reliable, single-request escalation path available to any workspace-scoped builder holding a valid API key on Enterprise deployments with the EXPANDED_PUBLIC_API feature enabled. The exploit requires no social engineering, no race conditions, and no external dependencies—it is deterministic and reproducible by any authenticated workspace-scoped builder. The preconditions (valid API key + Enterprise license) are realistic and commonly deployed in production environments. This is not a theoretical vulnerability; the SDK code explicitly processes arbitrary role properties without scope validation.

Detection Guidance

Log Indicators:

• POST requests to /api/public/v1/roles/assign where the caller's builder.global is false but the request body contains builder.global: true or admin.global: true
• Rapid or suspicious role assignments originating from service accounts or API keys with workspace-scoped permissions
• Audit log entries showing global admin grants immediately following role assignment API calls
• Authentication tokens with limited scope (workspace-builder) creating global-scope resources

Detection Signatures:

• Monitor HTTP request bodies for POST /api/public/v1/roles/assign containing keys matching /^(admin|builder)\.(global|apps)/
• Flag requests where the authenticated user's role scope is narrower than the role properties being assigned
• Alert on any role assignment expanding builder or admin properties to global scope from non-admin callers

Mitigation Steps

1. Immediate Patch: Implement a whitelist of assignable properties in the controller; filter assignmentProps to exclude builder.global, admin.global, and other tenant-wide properties.
2. Authorization Enforcement: Add explicit scope validation in the SDK: verify that only global admins or proper authorization holders can assign global roles. Reject workspace-scoped builders attempting to modify global scope.
3. Input Validation: Use schema validation (e.g., joi, zod) to enforce which role properties are assignable via the public API, separate from internal SDK calls.
4. Audit Logging: Ensure all role assignment operations log the caller's effective permissions, the target properties, and the resulting user state.
5. Workaround (if unpatched): Restrict access to /api/public/v1/roles/assign to global admins only via WAF or reverse proxy rules; disable EXPANDED_PUBLIC_API license feature if not required.
6. Review: Audit all workspace-scoped builder API keys created in the last 90 days for suspicious role assignment activity.

Risk Assessment

Likelihood of Exploitation: Very High. The vulnerability requires only a valid workspace-scoped API key (common in enterprise Budibase deployments) and a single HTTP request. No sophisticated tooling or insider knowledge is required. Any developer or contractor with workspace-builder permissions can exploit this undetected.

Threat Actor Interest: Critical. This enables complete lateral movement and persistence: a compromised or malicious workspace builder becomes a global admin, gaining full tenant control, data access, and ability to modify authentication mechanisms. Cloud environments and multi-tenant SaaS deployments are particularly high-value targets.

Wild Exploitation Risk: High, especially post-disclosure. The fix requires code changes; organizations on older Budibase versions remain vulnerable indefinitely unless patched. Enterprise customers with the EXPANDED_PUBLIC_API feature are at immediate risk.