In Budibase server (<=3.38.1), when an SSO-authenticated user tests an automation, their OAuth2 tokens are included in the user context bindings and passed through the automation execution pipeline. The full automation test result, including these tokens, is broadcast via WebSocket to all builders connected to the same app and stored in an in-memory cache keyed by app and automation IDs. This design flaw allows any co-builder of the same app to retrieve another user's OAuth2 access and refresh tokens either by listening to WebSocket events or by polling the test status endpoint. The tokens provide access to external APIs and persistent access via refresh tokens. The vulnerability is due to lack of sanitization of sensitive tokens before broadcasting or storing test results.

OAuth2 access tokens and refresh tokens for external services (e.g., Google Workspace, Azure AD, GitHub) are exposed to any builder user connected to the same Budibase app. Attackers can use these tokens to access external APIs as the victim user and maintain long-term access by generating new access tokens from refresh tokens. The exposure is passive via WebSocket broadcasts and active via test status polling. The tokens remain accessible in memory for approximately 5 minutes, increasing the window for exploitation.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The recommended fix is to sanitize automation test results by stripping OAuth2 tokens before broadcasting or storing them. Specifically, tokens should be removed from the results passed to the progress emission and test status endpoints. Until a patch is available, restrict builder user access to trusted users only and avoid testing automations with SSO-authenticated users in shared app environments.