Fix CVE-2026-121939 in Databasement: upgrade and review OIDC links

Upgrade Databasement to 1.10.9 or a later supported fixed release, and review existing OIDC identity links. CVE-2026-121939 affects versions before 1.10.9. The vulnerable email-linking flow can attach an external identity to an existing local account without checking whether the identity provider verified ownership of that email address.

The vendor advisory identifies the affected conditions: Generic OIDC login, automatic email linking, and an identity provider on which someone can present another person's email without verifying it. Automatic linking is enabled by default. A linked identity can continue signing in after a local password reset, so patching and password resets alone do not repair a previously unwanted link.

Choose the fixed release and check applicability

Inventory all application instances and background workers. Check whether Generic OIDC is enabled and whether OAUTH_AUTO_LINK_BY_EMAIL is enabled. Review who controls email addresses at the configured provider. A deployment using another login method should still upgrade, but the cited vulnerability concerns OIDC email linking; it does not establish that every authentication provider is affected.

The fixed OAuth service checks the provider's email-verification claim before creating an email-based link and preserves the local password. Returning logins with an existing provider/user-ID link follow a separate path.

Preserve the new verification policy

In 1.10.9, an explicit email_verified=false is refused for OIDC email linking. A missing claim is also refused by default.

The vendor SSO documentation describes an exception, OAUTH_OIDC_TRUST_EMAIL_WITHOUT_VERIFIED_CLAIM, which defaults to false. Providers such as Microsoft Entra ID may omit the claim. Leave the exception disabled unless you have verified that users cannot choose or change the email address issued by that provider. It permits a missing claim; it does not override an explicit false claim.

Do not enable this exception simply to clear a login error. Establish the provider's ownership guarantees, or retain another approved login/recovery method while correcting the integration.

Apply the update

1. Prepare a consistent recovery set. Back up the application database, persistent data and deployment configuration using your secured backup procedure. Preserve the existing application encryption key and the ability to recover an authorized administrator account. Do not generate a new key as part of an ordinary upgrade.
2. Stage the fixed artifact. Use synthetic accounts and a test identity provider in an isolated environment. The vendor's versioning guide defines exact container tags such as davidcrty/databasement:1.10.9 and matching Helm chart versions. Record the selected image digest or source revision so the deployed artifact is reproducible.
3. Update the deployment method you use. For Docker, pull the selected fixed image and recreate the application container with the existing data volume and configuration. For Compose, update and recreate both application and worker services. For Helm, select the fixed chart/application version and preserve your reviewed values. Container startup runs migrations automatically; inspect their outcome.
4. Handle source installations explicitly. Check out the fixed tag, install its locked dependencies, build its assets, apply migrations, clear stale configuration caches and restart the application and queue worker through your normal deployment process. The release's composer.json requires PHP 8.5; the native-install documentation still contains older PHP examples. Check the actual release requirements before deployment.
5. Verify access and background work before reopening. Confirm every instance uses fixed code and the intended configuration. Check administrator recovery, ordinary login, queue workers, scheduler and a harmless backup/restore exercise using synthetic data and a test destination.

Use the vendor's Docker, Compose and native deployment instructions for your environment. When upgrading from 1.9 or earlier, also apply the 1.10 worker migration; customized worker commands and file ownership need attention.

Verify login behavior and normal operation

Use only synthetic low-privilege accounts in staging. Exercise the configured provider through its normal login flow, with a new identity link for each linking test.

Check password login and two-factor policy where applicable. Verify that OIDC group mappings do not unexpectedly change organization access or roles. Confirm queue jobs and scheduled backups still complete, and restore a harmless test backup into an isolated destination. Successful authentication alone does not validate database credentials, storage permissions, backup integrity or restore behavior.

The vendor's OAuth regression tests cover claim handling, password preservation and returning identities. Their presence in the repository is not evidence that your deployment ran them.

Containment, existing links and rollback

If upgrading must wait, temporarily disable Generic OIDC and confirm the change is effective on every instance, while retaining a tested authorized recovery path. Disabling automatic email linking can stop new email-based links, but it does not disable logins through an existing provider/user-ID link.

Review existing linked identities, especially privileged accounts, against approved identity-provider subjects and account owners. Investigate unexpected links and active sessions. Revoke unwanted links and sessions through an authorized recovery/incident-response procedure before restoring access. A password reset does not remove the external identity binding. An upgrade also does not reconstruct a password that an earlier link cleared.

A rollback below 1.10.9 restores the vulnerable linking behavior. Keep OIDC contained during recovery, and assess database migration compatibility before restoring an earlier application image. Restore a consistent application database/data/configuration set only through a recovery plan that returns to fixed code.

Evidence and limits

The CNA records public disclosure on November 3, 2026, at 23:19:08 UTC. Original CVE Program publication was November 4, 2026, at 12:31:18 UTC. VulnCheck supplies CVSS 4.0 9.2 and CVSS 3.1 8.1; the vendor advisory labels the issue High. Research/test date: November 4, 2026 UTC. See the CVE Program record and Casco CVE page.

Independent checks compared the actual pinned OAuthService linking component in 1.10.8 and 1.10.9 with synthetic Socialite/config dependencies and an in-memory test account. The older component accepted unverified or missing claims and cleared the synthetic password. The fixed component refused explicit false and default missing claims, honored the documented missing-claim exception, and preserved the password. Verified-email, disabled-linking and non-OIDC controls also matched their expected behavior. These were component checks, not complete authentication flows.

The sanitized evidence distinguishes independently executed component checks from source guidance. A component result does not establish successful OIDC token validation, browser login, session revocation, real database transactions, role enforcement, or complete backup/restore operation. Verify those against the deployed application.