CVE-2026-121939 in Databasement
Summary
by MITRE • 11/04/2026
Databasement before 1.10.9 contains an authentication bypass vulnerability in OAuthService::findOrCreateLocalUser() that links OIDC identities to local users by email without checking email_verified. Attackers can register an identity provider account with a victim's unverified email to log in as any user, including the super-admin, and retain access after password resets.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in Databasement versions prior to 1.10.9 represents a critical authentication bypass flaw rooted in improper validation of identity provider claims during the account linking process. Specifically, the function OAuthService::findOrCreateLocalUser() is designed to associate OpenID Connect identities with local user accounts based on email addresses. However, this implementation fails to verify whether the email address provided by the external Identity Provider has been confirmed as valid and owned by the authenticating party. In standard security practices for federated identity management, relying solely on an unverified email claim from a third-party provider introduces significant risk because it assumes that whoever controls the OIDC session also legitimately owns the associated email account. This assumption is flawed when the local system does not enforce its own verification status or cross-reference with trusted signals indicating ownership confirmation.
From a technical perspective, this flaw allows an attacker to exploit the trust relationship between Databasement and external OAuth providers such as Google, GitHub, or other OIDC-compliant services. By registering for an account on one of these identity providers using an email address that belongs to a victim but has not yet been verified by that provider, or in cases where verification is bypassed or delayed, the attacker can initiate an authentication flow against Databasement. The application accepts this unverified claim and either creates a new local user linked to that email or associates it with an existing account if one exists. Consequently, the attacker gains immediate access to the victim's account without possessing the actual password or completing any multi-factor authentication steps required by the local system. This is particularly dangerous because it effectively nullifies the security controls intended for local accounts, including strong passwords and two-factor authentication, since entry is granted through the external identity provider instead.
The operational impact of this vulnerability is severe, extending beyond simple unauthorized access to potential full administrative takeover. Since the flaw affects the core user linking mechanism, an attacker can target high-privilege accounts such as super-administrators by registering OIDC identities with their email addresses. Once logged in as a privileged user, the attacker gains unrestricted control over the database infrastructure, potentially leading to data exfiltration, modification of critical configurations, or complete system compromise. Furthermore, the persistence aspect of this vulnerability is notable; even if an administrator detects the intrusion and resets the local password for the compromised account, the attacker retains access because their entry point remains tied to the external OIDC identity rather than the local credentials. This makes remediation through standard credential rotation ineffective unless the linked external identities are also explicitly revoked or removed from the user profile.
This issue aligns with CWE-287 Improper Authentication and CWE-613 Insufficient Session Expiration, as it involves bypassing authentication mechanisms and maintaining unauthorized access despite security controls being applied locally. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1078 Valid Accounts, specifically the technique of using valid accounts obtained through phishing or identity provider compromise, although in this case, the account is technically created via a logic flaw rather than stolen credentials. It also reflects aspects of T1528 Steal Application Access Token if the OIDC tokens are misused to maintain persistence. To mitigate this risk, organizations must upgrade Databasement to version 1.10.9 or later where the code has been patched to enforce email verification checks before linking identities. Additionally, administrators should review existing user accounts for any suspiciously linked external identities and remove them if they were created under questionable circumstances. Implementing strict validation policies that require both local password authentication and verified OIDC claims can further harden the system against such bypass attempts in future deployments.