本文へ移動
English version →
ログイン 新規登録
JA EN FR
SecPulse
重大 9.9 急ぎ度: 至急

SuperTokens Coreに別アプリ乗っ取りの脆弱性、修正版あり

認証サーバーSuperTokens Coreで、1つのアプリのAPIキーから同じ接続URIドメイン配下の別アプリを乗っ取れる脆弱性が公表されました。該当構成なら系列ごとの修正版に更新し、APIキーの書き換えがないかも確認します。

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

急ぎ度: 至急

CVSS v3は9.9で修正版が全系列に出ており、該当する構成では1つのアプリのAPIキーだけで同じドメイン配下の別アプリのユーザーとセッションを操作されるためです。

関係があるか

ライセンスを使うマルチテナント構成のSuperTokens Coreで、非デフォルトの接続URIドメイン（CUD）の下に複数のアプリを置き、アプリごとに別のapi_keysを設定している組織が対象です。アプリを1つしか置いていない構成は、悪用の前提に当てはまりません。

製品影響を受ける版修正版
SuperTokens Core（supertokens-core） 6.0系から12.3系までの各系列で、下に挙げる系列ごとの修正版より前の版 6.0.24、7.0.23、8.0.7、9.0.6、9.1.6、9.2.7、9.3.5、10.0.8、10.1.9、11.0.9、11.1.4、11.2.4、11.3.8、11.4.8、12.0.11、12.1.2、12.2.1、12.3.1（使っている系列に対応する版）

確かめ方

  1. 1稼働中のcoreの版を確認し、自分の系列の修正版より前かどうかを見ます。
  2. 2マルチテナント機能をライセンス付きで有効にしているかを確認します。
  3. 3非デフォルトのCUDの下に複数のアプリがあり、アプリごとに別のapi_keysを使っているかを確認します。
  4. 4いずれかのアプリのAPIキーを、開発委託先や運用ツールなど、本来の管理者以外が持っていないかを洗い出します。

何が起きたか

SuperTokens Coreで、あるアプリに発行されたAPIキーを使って、そのアプリの親にあたる接続URIドメインの設定を書き換えられる脆弱性が見つかりました。APIキー自体が書き換え対象に含まれるため、同じドメインの下にある別のアプリのユーザーやセッションまで操作される恐れがあります。

原因は、マルチテナント機能の権限確認にあります。ドメインを更新する場面で、アプリ側の更新元が同じドメインに属していることだけを見ており、更新元がそのドメインの公開アプリ・公開テナントであることまでは確認していませんでした。隣り合う確認はもっと厳密で、テナントやアプリの更新では識別子まで照合しています。さらにapi_keysが保護対象の設定に入っていなかったため、更新リクエストにそのまま新しいキーを載せられました。

副次的な変種もあります。v2の作成・更新ハンドラーでは識別子が省略可能で、省略すると対象が基底テナントになり、権限確認とエンタープライズ機能の確認が働きません。この経路ではfirstFactors、必須の第2要素、レシピの有効化フラグが書き換えられ、ログインの完全性と可用性に影響します。coreConfigは基底テナントでは拒否されるため、キーの窃取には至りません。

GitHubのアドバイザリは2026年10月16日付で、CVEとしての公表は11月9日です。報告者は複数おり、再現が確認されたのは12.2.0の公開PostgreSQLイメージでした。

攻撃の流れ

  1. 1

    キーを握る

    同じドメインの下にあるアプリの1つについて、有効なAPIキーを持っています。

  2. 2

    親の設定更新

    そのキーで親のドメインの設定を更新すると、権限確認をすり抜けます。

  3. 3

    キーの差し替え

    親のAPIキーに続いて、兄弟アプリのAPIキーも書き換えます。

  4. 4

    兄弟アプリ乗っ取り

    ユーザーの読み書きやセッション発行ができ、正規のキーは使えなくなります。

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

どう悪用されるか

悪用に必要なのは、ネットワーク経由でcoreのAPIに届くことと、いずれか1つのアプリの有効なAPIキーです。利用者の操作は要らず、攻撃の複雑さは低いとされています。前提となる構成は、ライセンスを使うマルチテナント機能が有効で、1つのCUDの下に複数のアプリがあり、アプリごとにキーが分かれていることです。

悪用されると、兄弟アプリのユーザーと、セッションの読み書きを許してしまいます。攻撃者は任意のユーザーとして認証でき、兄弟アプリに作ったダッシュボードユーザーを足がかりに居座れます。その兄弟アプリの正規のキーはキーの差し替えで使えなくなり、アプリ側からはAPI呼び出しが401で失敗する形で表に出ます。

副次的な変種では、アプリ側のキーで基底テナントのログイン設定を変えられます。こちらはキーの窃取ではなく、認証方式の無効化や有効化によるログインの不整合と停止が主な被害です。

今すぐやること

  1. 1

    系列ごとの修正版に更新する

    使っている系列と同じ系列の修正版に、coreを更新します。複数のコンテナーやノードで動かしている場合は、すべて更新します。

    docker ps --format '{{.Names}}\t{{.Image}}'
  2. 2

    APIキーの書き換えを確認する

    CUDと各アプリのapi_keysに、自分たちが設定していない値が入っていないかを調べます。アプリ側のAPI呼び出しが突然401で失敗していたら、キーが差し替えられた可能性があります。変更の経緯を追えない場合は、更新後にキーを発行し直します。

  3. 3

    ユーザーとセッションの異常を調べる

    各アプリのダッシュボードユーザーに、見覚えのないものがないかを確認します。あわせて、ログに不審なセッション発行や、アプリのキーによるCUDの更新リクエストが残っていないかを見ます。

  4. 4

    基底テナントの設定を見直す

    基底テナントのfirstFactors、必須の第2要素、レシピの有効化フラグが、意図した状態のままかを確認します。

すぐ更新できないとき

同じCUDの下に複数のアプリを置き、アプリごとにキーを分けているマルチテナント構成には、設定だけで防ぐ回避策が示されていません。修正版に更新するまでのつなぎとして、coreのAPIに届く接続元を信頼できるバックエンドだけに絞り、各アプリのAPIキーを持つ人を最小限にしておきます。これで危険は減らせますが、脆弱性そのものはふさがりません。

背景

SuperTokens Coreはオープンソースの認証サーバーで、ログイン、セッション、ユーザー情報を一手に扱います。マルチテナント機能では、CUD、アプリ、テナントの順に階層があり、アプリごとのAPIキーでcoreを呼び出します。1つのCUDに複数のアプリを収容できるので、顧客や事業部ごとにアプリを分けて運用している組織も少なくないでしょう。

今回の脆弱性は、CWE-639とCWE-863に分類される認可の不備です。上位の階層に対する更新を、下位の階層の資格情報で通してしまう点が特徴です。アドバイザリによると、アプリ同士の境界はプロジェクト自身の権限テストでも守るべき境界とされており、その境界が親のドメインの更新を経由して崩れていました。認証サーバーでは、セッションを発行できることが、そのままなりすましにつながります。

よくある質問

Q.修正版に更新すれば、すでに書き換えられたキーも元に戻りますか。
A.戻るとは示されていません。修正は権限確認を厳しくするもので、更新前に書き換えられたキーや作られたダッシュボードユーザーは自動では取り消されないと見ておくほうが安全です。更新のあとに、キーとユーザーの内容を自分で確認してください。

まだ分かっていないこと

  • 実際の攻撃で悪用された事例は公表されていません。
  • 影響範囲には6系から9系も含まれますが、再現が確認されたのは12.2.0で、脆弱な権限確認の分岐は10.0.0で導入されたと説明されています。古い系列での再現状況は公表されていません。

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

原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。

SuperTokens Core is an open source authentication server. From 6.0.0 until 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, 9.2.7, 9.3.5, 10.0.8, 10.1.9, 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, Multitenancy.checkPermissionsForCreateOrUpdate in src/main/java/io/supertokens/multitenancy/Multitenancy.java does not adequately authorize updates to a parent connection URI domain or the base tenant. In a licensed multi-tenant deployment with multiple applications under one non-default connection URI domain and separate api_keys, an attacker holding one application's valid API key can update the parent domain because the CUD-target branch checks the domain without requiring the source application and tenant to be public. Because api_keys is not protected, the attacker can replace the parent key and then sibling application keys, read or modify sibling users, obtain sessions as those users, establish persistence through a sibling dashboard user, and lock out the sibling application's own key. In the advisory's v2 create or update handlers, omitting the optional identifier produces a base-tenant target that skips the permission branches and enterprise-feature gate, allowing changes to firstFactors, required secondary factors, and recipe-enabled flags that affect login integrity and availability. The base-target variant still rejects coreConfig and does not establish key theft. This issue is fixed in versions 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, 9.2.7, 9.3.5, 10…

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

参照URL

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