Summary
Budibase contains an authentication bypass in its OIDC and SSO login flow that can allow an attacker to claim a pending invitation by asserting the invited user's email address through a trusted identity provider. The attacker may inherit the invitation's privileges, including builder or global administrator access, when the tenant accepts unverified identity claims.
Affected context
The issue occurs in Budibase deployments using the OIDC or SSO login path and allowing authentication through a tenant-trusted identity provider. Risk is present when a pending invitation is matched using only the IdP-asserted email address, without requiring a valid invitation code, confirming the email_verified claim, or excluding privileged invitations from this path.
Exploit preconditions
- Attack surface: OIDC or SSO authentication for a Budibase tenant - Required access: The ability to register with, or otherwise control, an
identity at an identity provider trusted by the tenant
- Required claim: The attacker must be able to assert the email address
associated with a pending invitation, including where email_verified is
false
- Trigger point: The pending-invite lookup performed during SSO login when
no existing account matches the incoming subject
- Why exploitation is possible: The invite lookup trusts the asserted email
without validating an invite code or applying the email verification gate
used for existing-account matching
Why this happens
The authentication flow applies stronger identity checks when locating an existing account but uses a weaker, email-only comparison for pending invitations. Treating an IdP-asserted email address as sufficient proof of invitation ownership allows an untrusted or unverified identity to consume another principal's invitation and receive its permissions. This behavior maps to CWE-287, Improper Authentication, because the system fails to adequately authenticate the party claiming the invited identity.
Potential impact
- An attacker may take over the invited principal's Budibase account.
- The attacker could inherit builder, administrator, or other invitation-granted privileges.
- A privileged invitation could enable compromise of the tenant and its applications.
- The attacker may access sensitive datasources, including production credentials.
- Automations and application data could be modified, disrupted, or exposed.
- The legitimate invitee may be prevented from completing onboarding because the invitation is consumed.
General mitigation guidance
Mitigation generally focuses on making invitation redemption an explicit, strongly authenticated operation rather than an email-based identity match. Secure-by-default designs can require a cryptographically strong, single-use invitation token or code, bind redemption to the intended identity through a verified account-linking process, and require a trustworthy email_verified signal where email is used. Invitation processing should apply the same identity assurance rules to existing accounts and pending invites, reject ambiguous or unverifiable claims, and apply additional controls to privileged invitations. Tenant and service permissions should follow least privilege, while sensitive datasource access and administrative actions can require separate step-up authentication and audit controls.
How teams detect issues like this
Detection approaches can include static analysis and code review rules that flag authentication or invitation decisions based solely on user-controlled email claims. Reviewers can search for identity-provider assertions used without validation of subject, issuer, audience, signature, email_verified, invitation tokens, or account-linking state. Runtime monitoring can alert on invitation redemption by newly registered IdP identities, unverified email claims, unusual privileged-account creation, and rapid changes to datasource or automation permissions. Policy enforcement in CI can require security review for SSO, account-linking, and invite-consumption logic; automated review tools may help identify these patterns.
