CVE-2026-73302

CVE-2026-73302 is an OIDC authentication bypass in Budibase where the platform accepts unverified email claims during SSO account linking. The vulnerability lives in how Budibase processes the `email` claim from an identity provider without checking the companion `email_verified` claim—an optional field that the OIDC spec deliberately separates because providers may assert "this user is [email protected]" without asserting "this email has been verified." Budibase appears to have treated the absence of a verification check as functionally equivalent to verified. There's a second failure: the fallback account-linking mechanism in sso.ts that looks up users by email if they don't exist with the linked IdP. This convenience feature—likely added to avoid manual account provisioning—allows account linking to succeed on the basis of an unverified email, conflating ease of integration with authorization. What makes this noteworthy isn't the implementation oversight (one missing check) but where that compromise lands. Budibase is a low-code platform. Compromising an account doesn't give you a login session—it gives you everything that user built: dashboards, database connectors, automations, access controls, and the data flows between them. The blast radius is in the application layer, not the authentication layer. The IdP-access prerequisite is real but narrower than it first appears. An IdP misconfiguration, a test environment sharing production IdP settings, or an admin who configures a lenient IdP for convenience can all create the exploit condition without a malicious insider. Low-code platforms specifically attract non-expert administrators who may not understand what their IdP is asserting about email verification. Check your Budibase instance: confirm you're on version 3.39.30 or later, audit your SSO configuration to understand what your IdP actually asserts about email_verified, and treat the account-linking fallback as a high-risk path. The patch addresses this instance; the pattern (optional claim becoming implicit trust) has CVE history stretching back years in the OAuth/OIDC ecosystem and will recur in future integrations. Your SSO integration guidance should explicitly document what your IdP asserts and whether email_verified is reliable—don't treat it as a black box.

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