Summary
A missing per-application authorization check in Budibase allows a builder with access to one workspace to alter group role mappings for applications in other workspaces. This may let the builder grant themselves administrative roles beyond their authorized workspace boundary.
Affected context
The issue occurs in Budibase deployments where builders can access the application group-management endpoint and role assignments are processed without confirming that the target application belongs to an authorized workspace. The risk is present when workspace and application boundaries are not independently enforced for each authorization-sensitive operation.
Exploit preconditions
- Attack surface: The application group and role-management API - Required access: Builder-level access to at least one workspace - Trigger point: A request that updates user group role mappings for an
application
- Why exploitation is possible: Authorization is checked at an insufficient
workspace or operation scope, allowing assignments affecting applications
outside the builder's permitted workspace
Why this happens
The underlying bug is an authorization design failure in which the endpoint does not verify authorization for the specific target application and its owning workspace before applying role changes. This maps to CWE-269, Improper Privilege Management, because a lower-privileged builder can cause the system to grant or modify privileges outside the intended administrative boundary. The insecure pattern is trusting a caller's general workspace authority instead of enforcing object-level authorization for every affected resource.
Potential impact
- A builder may gain administrative privileges in another workspace
- Unauthorized users could modify application access and group memberships
- Cross-workspace confidentiality or integrity boundaries could be weakened
- Administrative actions may be performed without the target workspace owner's approval
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization at the point where each role mapping is changed. Authorization checks can verify the caller, target application, owning workspace, requested role, and affected users together rather than relying on broad builder permissions. Secure-by- default designs can deny cross-workspace mutations, use explicit capability checks, and separate workspace administration from application-level management. Reducing trust in client-supplied identifiers, validating relationships server-side, applying least privilege, and recording authorization decisions can further limit exposure.
How teams detect issues like this
Detection approaches can include static analysis and code review for endpoint handlers that accept application, workspace, group, or role identifiers without verifying their relationships. Reviewers can look for authorization checks performed only at login or workspace-selection time, as well as mutation paths that do not reauthorize every target resource. API policy testing can attempt permitted and denied cross-workspace combinations, while audit monitoring can flag role changes made by builders outside their workspace scope. Automated security review tools may help identify missing object-level authorization patterns.
