Description

Budibase versions before 3.45.0 fail to validate per-app authorization in the POST /api/global/groups/:groupId/apps endpoint, allowing builders to assign application roles across workspace boundaries. A builder of a single workspace can exploit missing per-app authorization checks to grant themselves admin roles in other workspaces by modifying user group role mappings.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-26T14:16:53.000Z",
  "pubdate": "2026-09-26T14:16:53.000Z",
  "executiveSummary": "Budibase versions prior to 3.45.0 contain a critical broken access control vulnerability within the application's authorization logic.\nThe vulnerability resides in the POST /api/global/groups/:groupId/apps endpoint, which fails to enforce strict validation of per-app authorization boundaries.\nAn authenticated user with 'builder' privileges in one workspace can leverage this flaw to manipulate user group role mappings associated with applications in entirely different, unauthorized workspaces.\nThe primary risk implication is horizontal and vertical privilege escalation, enabling unauthorized users to grant themselves or others administrative roles across workspace boundaries.\nThis vulnerability compromises the integrity of workspace isolation and application-level access control, potentially allowing unauthorized access to sensitive internal application data and administrative configuration settings.\nExploitation requires a valid builder account within the platform, but does not necessitate additional permissions for the targeted external workspace.",
  "technicalDetails": "The root cause of this vulnerability is an insecure authorization check implementation within the Budibase API backend, specifically regarding the assignment of application-level roles to user groups.\nThe endpoint POST /api/global/groups/:groupId/apps is designed to manage role mappings; however, it lacks mandatory per-app authorization verification against the requesting user's security context.\nBecause the server-side code does not validate whether the authenticated 'builder' has administrative oversight or legitimate access to the target application being modified, the application fails to enforce the logical boundary separating independent workspaces.\nThe attack flow proceeds as follows: A malicious actor with 'builder' level access identifies the groupId of an existing user group and the resource identifier for an application within a separate workspace. The attacker constructs a POST request to the vulnerable endpoint, injecting the target groupId and the unauthorized application's parameters. Since the API lacks cross-workspace validation, the server processes the request as legitimate, updating the group role mapping in the database.\nBy successfully modifying the role mappings, the attacker elevates their own permissions or the permissions of a compromised account to include administrative roles within the target workspace. This bypasses the platform's intended multi-tenant security architecture.\nThe vulnerability affects all Budibase instances running versions prior to 3.45.0. Authentication as a builder is required to reach the API, but no further interaction with the victim workspace is needed. The lack of an access control list (ACL) check against the resource ownership ensures that the request succeeds regardless of the requester's legitimate relationship to the target application.\nPost-exploitation, the attacker gains persistent elevated privileges, permitting the manipulation of application settings, data exposure, or complete compromise of the target application. This represents a significant failure in the application's authorization lifecycle management and violates the principle of least privilege."
}