Description

Budibase versions 3.41.0 before 3.45.0 contain an authentication bypass in the OIDC/SSO login path of @budibase/server. In sso.authenticate, when no existing user matches the incoming SSO subject, the server looks up pending user invites by the IdP-asserted email address alone — without validating an invite code and without an email_verified check (the email_verified gate protects only the existing-account lookup). An attacker who can register at an IdP that the tenant trusts for OIDC and assert a victim's invited email address (even with email_verified=false) claims the pending invite and inherits all of its granted privileges, including builder and admin.global, with no admin exclusion. This results in takeover of the invited principal and, for admin invites, full tenant compromise (access to all apps, datasources including production credentials, and automations); the invite is consumed, denying onboarding to the legitimate invitee.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-26T14:16:52.720Z",
  "pubdate": "2026-09-26T14:16:52.720Z",
  "executiveSummary": "Budibase versions 3.41.0 through 3.44.x are affected by a critical authentication bypass vulnerability within the @budibase/server component.\nThe vulnerability resides in the sso.authenticate function, which improperly handles the provisioning of users via OIDC/SSO when a pending invite exists.\nAn unauthenticated attacker can exploit this flaw by asserting the email address of an invited user via a trusted Identity Provider (IdP), regardless of the email_verified claim status.\nSuccessful exploitation allows an attacker to claim a pending invite and inherit the associated user privileges, including administrative roles such as admin.global.\nThis represents a complete account takeover scenario, leading to total tenant compromise, including unauthorized access to applications, production data sources, and automated workflows.\nThe vulnerability poses a severe risk to organizations using OIDC/SSO integration, as it enables unauthorized privilege escalation by bypassing the invite validation mechanisms.",
  "technicalDetails": "The root cause of this vulnerability lies in an insecure implementation of the user provisioning logic within the sso.authenticate function of @budibase/server. When the system processes an OIDC assertion, it attempts to resolve the identity to an existing account. If no matching account is found, it transitions to a secondary lookup mechanism designed to identify pending user invitations based solely on the email address provided in the IdP claim.\nThe flaw manifests because the application fails to validate critical security parameters during this transition. Specifically, the system neglects to verify the presence or validity of an invite code, and it fails to ensure that the email_verified flag in the OIDC assertion is set to true. While the initial lookup for existing accounts correctly honors the email_verified gate, the fallback logic for pending invites relies exclusively on the raw email string.\nAn attacker can exploit this by utilizing an IdP that the Budibase tenant trusts for SSO. If the attacker initiates a login request for a target user's email address—even if that email is not verified at the IdP—the Budibase server will match the request against a pending invitation for that email. The server then automatically assigns the account to the attacker, consuming the invite in the process.\nThe attack flow is as follows: 1) An administrator generates an invitation for a user (potentially with high-level privileges). 2) The attacker, possessing the email address of the invitee, initiates an OIDC/SSO login process using a trusted IdP. 3) The IdP asserts the victim's email address in the ID token. 4) The sso.authenticate function receives the assertion, fails to find an existing user, and incorrectly maps the attacker's session to the pending invite record. 5) The attacker is granted the permissions defined in the invite, bypassing all invitation validation checks.\nThe post-exploitation impact is total tenant compromise. Because the attacker inherits the full scope of the invitation—which may include administrative or builder privileges—they gain unfettered access to all applications and sensitive data, including database credentials, API keys, and environment variables configured within automations. This vulnerability effectively weaponizes the invitation system, allowing attackers to hijack legitimate user onboarding processes."
}