本文へ移動
English version →
ログイン 新規登録
JA EN FR
SecPulse
高 9.2 急ぎ度: 早めに

Databasementの乗っ取り脆弱性、1.10.9で修正

Databasementの1.10.9より前の版に、OIDCログインを経由して他人のアカウントに入られる脆弱性があります。OIDC連携の有無と版を確認し、1.10.9へ更新してください。

CVE-2026-121939 公開 更新 執筆・監修: 佐々木 航 人が監修しながらAIを活用して執筆
画像は生成 AI で作成したイメージです

急ぎ度: 早めに

CVSS v3は8.1、v4は9.2でスーパー管理者の乗っ取りまで届く内容ですが、悪用の条件がやや厳しく、公表と同日に修正版1.10.9が出ています。

関係があるか

Databasementを自社で運用し、OIDC（外部のIDプロバイダー）でのログインを使っている組織が対象です。パスワードだけで運用している環境は、OIDC連携の設定が無ければ影響は小さいとみられますが、確定ではないため版は確認してください。

製品影響を受ける版修正版
Databasement（David-Crty） 1.10.9より前のすべての版 1.10.9

確かめ方

  1. 1稼働中のDatabasementの版を、管理画面の表示か、コンテナーのイメージタグ、デプロイしたリリースの版から確認する。1.10.9より前なら対象です。
  2. 2認証設定でOIDCのプロバイダーを登録しているかを確認する。登録がある環境は、早めの更新を優先します。
  3. 3連携しているIDプロバイダーが、メールアドレスの確認が済んでいないアカウントの作成を許しているかを、IDプロバイダー側の設定で確認する。
  4. 4影響範囲の詳細（OIDCを使わない構成の扱いなど）は、GitHubのセキュリティアドバイザリで確認してください。

何が起きたか

DatabasementのOIDCログインに、本来ログインできないはずの他人のアカウントに入れてしまう脆弱性が見つかりました。スーパー管理者のアカウントも対象に含まれます。

ログイン処理のOAuthService::findOrCreateLocalUser()が、OIDCの利用者を既存のローカルユーザーに結びつける際、メールアドレスが一致するかだけを見て、IDプロバイダーが返すemail_verifiedを確認していません。そのため、メールアドレスが本人のものと確認されていなくても、同じ文字列なら同一人物として扱われます。分類はCWE-290で、修正版は1.10.9です。

攻撃の流れ

  1. 1

    他人のメールで登録

    攻撃者が、狙う利用者のメールアドレスを未確認のまま使い、IDプロバイダーにアカウントを作ります。

  2. 2

    OIDCでログイン

    そのアカウントでDatabasementのOIDCログインを行います。

  3. 3

    既存ユーザーに結合

    メールアドレスが同じというだけで、Databasementが既存ユーザーに結びつけます。

  4. 4

    管理者として操作

    スーパー管理者を含む任意のユーザーとして、画面と機能を使えるようになります。

公開されている情報をもとにした流れの例です。

どう悪用されるか

認証は不要で、ネットワーク越しに悪用できます。利用者の操作も要りません。ただし、Databasementが信頼するIDプロバイダーで、メールアドレスの確認が済んでいないアカウントを作れることが前提になるため、攻撃の難度は高めと評価されています。

成功すると、乗っ取った利用者の権限で、Databasementの情報の閲覧、変更、停止ができます。狙われるのがスーパー管理者なら、影響はアプリ全体に及びます。

もう一つ厄介なのは、パスワードを再設定しても侵入が止まらないことです。アカウントがIDプロバイダー側の別の身元と結びついたままになるためで、通常の初動である「パスワード変更」だけでは足りません。

今すぐやること

  1. 1

    1.10.9へ更新する

    Databasementを修正版の1.10.9以降に更新します。コンテナー運用なら、イメージタグを固定していないかを見直し、更新後に版が切り替わったことを確認します。

  2. 2

    管理者アカウントの状態を調べる

    更新前にOIDCログインが有効だった環境では、スーパー管理者を含む各アカウントの最近のログイン元と、見覚えのない操作が無いかを確認します。パスワード再設定の履歴があっても、侵入が続いている可能性があります。

  3. 3

    OIDCの連携状態を見直す

    各アカウントに結びついているOIDCの身元が、本人のものかを確認します。心当たりのない結びつきがあれば、アカウントの扱いをベンダーの告知に沿って整理し直してください。

  4. 4

    IDプロバイダー側の設定も確認する

    メールアドレスの確認が済んでいないアカウントの作成や、外部からの自己登録を許していないかを確認します。許している場合は、制限をかけると同種の問題を防げます。

すぐ更新できないとき

すぐに更新できないときは、OIDCログインを無効にするか、IDプロバイダー側でメール未確認のアカウント作成と外部からの自己登録を止めておきます。Databasementをインターネットに公開しているなら、社内ネットワークやVPNからだけ届くよう制限するのも有効です。どの設定が使えるかは、ベンダーの告知で確認してください。

背景

Databasementは、スーパー管理者のアカウントを持つ管理用のWebアプリです。OIDCに対応しているため、社内のシングルサインオンの基盤とつないで運用している組織もあります。こうしたアプリは、管理者のアカウントを奪われると、アプリが扱う情報と設定をまとめて握られます。

今回の問題は、外部のIDプロバイダーが返すメールアドレスを、本人確認の済んだ情報として扱ったことにあります。メールアドレスは、確認の手続きを経て初めて身元の手がかりになります。IDプロバイダーによっては、未確認のまま登録できる設計もあるため、アプリ側でemail_verifiedを見ないと、アカウントの結びつけ先を誤ります。

よくある質問

Q.OIDCを使わず、ローカルのパスワードだけで運用している場合は更新しなくてよいですか。
A.この脆弱性はOIDCログインの処理にあるため、影響は小さいとみられます。ただ、あとからOIDCを有効にする可能性があるなら、修正版への更新は済ませておくと安心です。
Q.更新が済んだら、それ以上の対応は要りませんか。
A.OIDCログインが有効だった期間は、すでにアカウントが結びつけられている可能性があります。更新だけでは過去の結びつきは消えないおそれがあるため、ログインの履歴と各アカウントの連携状態を確認してください。

この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。

影響パッケージ

種類パッケージ影響を受ける版修正版
David-Crty Databasement
1.10.9 未満
1.10.9
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

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.

出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory

参照URL

当サイトでは、アクセス解析と広告の効果測定のために Cookie を使います。株式会社Game のサイト共通の設定です。 詳しく