Summary
A workspace authorization flaw in Budibase allows builders to access chat identity-link records outside the workspace where they have permission. Under a tenant configuration with multiple workspaces, an attacker with builder access to one workspace may enumerate user IDs and external chat service identifiers belonging to other workspaces.
Affected context
The issue occurs in Budibase deployments where the chat-links API serves tenants containing multiple workspaces and authorization is evaluated without sufficiently restricting results to the caller's permitted workspace. The risk is greatest when builders are trusted for only a subset of tenant workspaces but the endpoint can return records from broader tenant scope.
Exploit preconditions
- Attack surface: The chat identity-link API endpoint
- Required access: Authenticated builder access to at least one workspace in the tenant
- Trigger point: A request to retrieve chat-link records
- Why exploitation is possible: The endpoint does not consistently apply workspace-level authorization when selecting or returning records
Why this happens
The underlying bug is an authorization-scoping failure. The endpoint permits a user with valid builder privileges in one workspace to receive records associated with other workspaces because the data query or authorization decision is not adequately bound to the caller's workspace permissions. This behavior maps to CWE-863: Incorrect Authorization, where access checks do not correctly enforce the intended resource boundary.
Potential impact
- Attackers may enumerate chat identity-link records across unauthorized workspaces
- User IDs and external chat service identifiers could be disclosed
- Organizations may experience cross-workspace privacy violations
- Exposed identifiers could support phishing, correlation, or follow-on attacks
- Tenant isolation assurances could be weakened
General mitigation guidance
Mitigation typically focuses on enforcing authorization at the resource and query layers rather than relying solely on route-level authentication.
Common defensive patterns include:
- Deriving the permitted workspace scope from the authenticated session or server-side authorization context
- Applying workspace constraints directly to database queries and result serialization
- Denying access by default when workspace context is missing, ambiguous, or mismatched
- Returning only the minimum identity data required by the requesting feature
- Separating tenant and workspace authorization policies and testing them independently
- Running authorization tests for same-workspace, cross-workspace, and unauthorized-resource scenarios
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and code review for endpoints that query records without tenant or workspace predicates
- Review of authorization middleware, query builders, and object-level permission checks
- Tests that use users with access to one workspace while requesting resources from another
- API monitoring for repeated enumeration patterns and unusual cross-workspace access
- Policy enforcement requiring explicit resource-scope checks for multi-tenant endpoints
- Automated security review tools that flag missing object-level authorization and excessive data responses
