CVE-2026-73308

The CVSS 5.7 score for CVE-2026-73308 obscures a fundamentally dangerous failure in how Budibase reasons about credential scope. The vulnerability stems from OAuth2 refresh tokens flowing through the app-room broadcast mechanism — a channel designed for sharing application-scope state like test progress across co-builders. This isn't an access control bug; it's a structural confusion about what belongs to users versus what belongs to the application. OAuth2 tokens are intrinsically bound to a specific user's authenticated session, yet Budibase's automation data model exposed them as a first-class field in trigger.outputs.user.oauth2, making them available to every builder with access to the automation channel. The co-builder prerequisite for exploitation is a misleading constraint. Low-code platforms are inherently multi-tenant collaborative workspaces — the trust model that makes Budibase useful is exactly the trust model this vulnerability exploits. Treating co-builder access as a meaningful security boundary in this context is like treating network adjacency as a meaningful constraint for local privilege escalation. What elevates this beyond a single CVE is the token type. OAuth2 refresh tokens provide persistent, renewable access. Unlike a short-lived bearer token, a stolen refresh token grants indefinite access unless the legitimate user explicitly revokes it through the OAuth2 provider. In a platform that positions itself as the integration layer for enterprise data sources — connecting to Google Workspace, GitHub, Salesforce, and internal databases — a stolen refresh token doesn't just expose Budibase; it exposes every system the victim builder ever connected via OAuth2. The fix — sanitizeAutomationTestResult with user-isolated progress — treats the symptom, not the disease. The underlying data model where trigger.outputs.user.oauth2 exists as a traversable path remains intact. This is ad-hoc output sanitization at its most fragile: it depends on enumerating dangerous fields rather than enforcing architectural boundaries between user-isolated credentials and application-scope state. Nothing prevents a future developer from adding trigger.outputs.user.sessionToken or a similar field through a different automation trigger, webhook callback, or progress channel. For defenders: audit your Budibase deployments for any automation triggers that consume or forward user OAuth2 state, not just the test-results channel. Check whether self-hosted instances are running versions that include the sanitizeAutomationTestResult fix — enterprise deployments often lag significantly behind on patching, and the refresh token exposure means that delay compounds rather than decays. Finally, review every external integration connected through Budibase's OAuth2 flows; a compromised refresh token may grant access to systems you didn't realize were in scope.

Reviewed through automated stages and approved by a human before publication.