CVE-2026-100684 in Budibase
Summary
by MITRE • 09/26/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Budibase versions prior to 3.45.0 represents a critical authentication bypass within the OpenID Connect (OIDC) single sign-on implementation of the @budibase/server component. This flaw specifically affects the sso.authenticate function, which is responsible for handling user identity assertions from external identity providers. The core technical deficiency lies in how the system processes new users who do not yet have an existing account on the platform but are associated with a pending invitation. When the server receives an OIDC assertion where no matching local user exists, it attempts to locate a corresponding pending invite record based solely on the email address asserted by the identity provider. Crucially, this lookup and subsequent claim process fails to validate the unique invite code required for secure redemption and omits any verification of the email_verified status from the IdP token. While an email_verified check is present in the logic path for existing account lookups, it is entirely absent when processing new invites, creating a significant gap in the authentication workflow that allows unauthorized privilege escalation.
The operational impact of this vulnerability is severe, enabling an attacker to hijack pending user accounts and assume their assigned roles without proper authorization. An adversary who can register at any identity provider trusted by the target tenant can manipulate the email address field in their OIDC token to match that of a victim who has been invited but not yet onboarded. By asserting this victim's email address, even if the IdP marks it as unverified (email_verified=false), the attacker successfully claims the pending invite. This action grants the attacker all privileges associated with the invitation, which can range from standard user access to high-privilege roles such as builder or global administrator. In cases where an admin-level invitation is targeted, this results in a complete compromise of the tenant environment. The compromised account gains unrestricted access to all applications, data sources containing production credentials, and automation workflows, effectively giving the attacker full control over the Budibase instance.
Beyond immediate privilege escalation, this vulnerability causes significant denial-of-service conditions for legitimate users. Because the pending invite is consumed upon successful authentication by the attacker, the intended recipient can no longer redeem their invitation to access the platform. This not only disrupts business operations and onboarding processes but also indicates that the security model relies heavily on out-of-band verification mechanisms that are bypassed in this specific code path. The lack of a mandatory invite code validation means that possession of an email address is sufficient for account takeover, ignoring standard best practices for secure invitation redemption which typically require both identity assertion and proof of control over the invited channel via a secret token.
From a classification perspective, this vulnerability aligns with CWE-287, Improper Authentication, as the system fails to adequately verify the identity of users during the login process. It also relates to CWE-640, Weak Password Recovery For Privileged Accounts, since the mechanism for recovering or establishing access via invitation is flawed and allows privilege escalation without sufficient proof of ownership. In terms of offensive security frameworks, this exploit maps directly to MITRE ATT&CK technique T1078, Valid Accounts, specifically involving the hijacking of valid but unactivated credentials. The attacker leverages a legitimate account state (pending invite) to gain unauthorized access, bypassing traditional authentication barriers through logical flaws rather than cryptographic breaks or input injection attacks.
Mitigation for this vulnerability requires an immediate upgrade to Budibase version 3.45.0 or later, where the logic has been corrected to enforce proper validation of pending invites. For organizations unable to patch immediately due to operational constraints, temporary mitigations should focus on restricting which identity providers are trusted by the tenant and ensuring that only verified email addresses from IdPs are accepted for new user creation if possible through configuration changes. Additionally, implementing strict monitoring around SSO login events can help detect anomalous patterns where multiple different subjects attempt to authenticate with the same pending invite email address, although this is a reactive measure rather than a fix for the underlying logic flaw. The primary defense remains applying the vendor-provided patch that enforces both invite code validation and appropriate checks on identity provider assertions during the new user registration flow.