CVE-2026-73308: Budibase OAuth Token Disclosure Flaw

CVE-2026-73308 Overview

CVE-2026-73308 is an information disclosure vulnerability in Budibase, an open-source low-code platform. Versions prior to 3.39.25 return automation test results containing trigger.outputs.user.oauth2 without user scoping. The packages/server/src/api/controllers/automation.ts controller broadcasts BuilderSocketEvent.AutomationTestProgress to the entire app room and stores progress in packages/server/src/automations/testProgress.ts shared across builders. A co-builder in the same app can receive or poll another SSO-authenticated builder's automation test and obtain their OAuth2 access and refresh tokens. The issue is fixed in version 3.39.25, which adds sanitizeAutomationTestResult and isolates progress by user.

Critical Impact
Co-builders can harvest another SSO-authenticated user's OAuth2 access and refresh tokens by observing or polling shared automation test progress.

Affected Products

Budibase versions prior to 3.39.25
Budibase server component (packages/server)
Budibase automation test workflow for SSO-authenticated builders

Discovery Timeline

2026-08-12 - CVE-2026-73308 published to the National Vulnerability Database (NVD)
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-73308

Vulnerability Analysis

The vulnerability sits in Budibase's automation testing subsystem. When a builder runs an automation test, the server executes triggers that may include SSO-authenticated context data. The result payload contains trigger.outputs.user.oauth2, which holds the access and refresh tokens tied to the executing user's identity provider session.

Budibase then broadcasts test progress and results using the BuilderSocketEvent.AutomationTestProgress websocket event scoped to the app room. Any authenticated builder joined to that room receives the broadcast. In parallel, the server persists in-flight progress in testProgress.ts without associating each entry with the initiating user. A separate builder can therefore poll the shared progress store to retrieve results they did not originate.

The weakness maps to [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor]. The disclosed OAuth2 tokens can be replayed against the identity provider to impersonate the victim within the scopes granted to Budibase.

Root Cause

Two issues combine to cause the exposure. First, automation test results are returned verbatim without stripping sensitive OAuth2 fields from trigger.outputs.user. Second, both the websocket broadcast channel and the testProgress store operate at app-room granularity rather than per-user, allowing any co-builder to receive or fetch another builder's test data.

Attack Vector

Exploitation requires an authenticated builder account with access to the same Budibase app as the victim, plus user interaction from the victim who must initiate an automation test. The attacker either listens passively on the builder websocket for AutomationTestProgress events or polls the shared progress endpoint. When the victim triggers a test, the response payload delivers OAuth2 access and refresh tokens to the attacker.

typescript

// Patch excerpt from packages/server/src/api/controllers/automation.ts
 } from "@budibase/types"
 import { testConnection } from "../../automations/email"
 import { getActionDefinitions as actionDefs } from "../../automations/actions"
+import { sanitizeAutomationTestResult } from "../../automations/sanitizeTestResult"
 import * as triggers from "../../automations/triggers"
 import {
   AutomationTestProgressEvent,

Source: GitHub Commit bca426d. The fix imports sanitizeAutomationTestResult to strip OAuth2 fields before returning or broadcasting test results.

Detection Methods for CVE-2026-73308

Indicators of Compromise

Unexpected AutomationTestProgress websocket subscriptions from builder accounts that did not initiate the test
OAuth2 tokens issued to Budibase being replayed from IP addresses or user agents inconsistent with the token owner
Polling requests against the automation test progress endpoint by builders other than the test initiator

Detection Strategies

Audit Budibase application logs for automation test executions and correlate the initiating user against websocket clients receiving BuilderSocketEvent.AutomationTestProgress events
Review identity provider logs for OAuth2 refresh or access token usage patterns that deviate from typical Budibase server-side call paths
Inventory Budibase deployments and flag any instance running a version below 3.39.25

Monitoring Recommendations

Enable verbose logging on the Budibase server for automation controller endpoints and websocket rooms
Forward Budibase and identity provider logs into a centralized analytics platform for cross-source correlation of token issuance and reuse
Alert on OAuth2 refresh token usage originating outside the expected Budibase server egress ranges

How to Mitigate CVE-2026-73308

Immediate Actions Required

Upgrade Budibase to version 3.39.25 or later on all self-hosted deployments
Rotate OAuth2 client secrets and revoke outstanding refresh tokens for any identity provider integrated with a vulnerable Budibase instance
Review the builder user roster for each app and remove accounts that no longer require access

Patch Information

The fix ships in Budibase 3.39.25. See GitHub Release 3.39.25, Pull Request #19107, and GitHub Security Advisory GHSA-gh4h-34gr-87r7. The patch introduces sanitizeAutomationTestResult to remove trigger.outputs.user.oauth2 from returned payloads and refactors testProgress.ts to scope progress entries per user.

Workarounds

Restrict builder role assignments so that each app has only one trusted builder until the upgrade is applied
Disable OAuth2-based SSO providers used inside Budibase automations until the environment is patched
Block builder-tier access from untrusted networks with reverse proxy or WAF rules to reduce the attacker population

bash

# Upgrade Budibase self-hosted deployment to the patched release
docker pull budibase/budibase:3.39.25
docker compose down
docker compose up -d

# Verify running version
curl -s http://localhost:10000/api/system/version