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

ape-volo-adminで管理者トークン偽造、3.6.1で修正

ape-volo-adminの3.6.1より前では、設定ファイルに固定された署名鍵で管理者トークンを偽造され、認証なしでAPIを全面操作されるおそれがあります。利用中の組織は3.6.1へ更新し、署名鍵の入れ替えと管理者操作の履歴確認まで進めてください。

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

急ぎ度: 至急

CVSS v3は9.8で認証なしにネットワーク越しで悪用でき、修正版3.6.1が出ている一方、KEVへの掲載は確認されておらず、公表は2026年11月2日と直近です。

関係があるか

ape-volo-adminを社内の管理システムや業務アプリの土台として運用し、APIがネットワークから到達できる組織が対象です。同梱の設定ファイルの署名鍵を変えずに使っている環境ほど危険です。

製品影響を受ける版修正版
ape-volo-admin（xianhc） 3.6.1より前のすべての版 3.6.1

確かめ方

  1. 1運用中の環境の版を確認します。リリース一覧や、ビルド時のタグ、デプロイ済みのアセンブリの版情報が手がかりです。
  2. 2Ape.Volo.Apiのappsettings.jsonにあるJWT関連の署名鍵が、配布物のままの値になっていないか確かめます。リポジトリの値と一致するなら、この脆弱性で偽造される状態です。
  3. 3ベンダーの告知とリリースノートで、自社が使っている版と修正の範囲を照合します。フォークや独自改修をしている場合は、修正のコミットが取り込まれているかも見てください。

何が起きたか

ape-volo-adminの3.6.1より前には、認証を回避して管理者になりすませる脆弱性があります。ログインの証明であるJWTに署名するための鍵が、appsettings.jsonに固定値で書き込まれていたことが原因です。

この鍵が配布物に含まれ、ソースも公開されているため、鍵を知った第三者は自分で管理者用のトークンを作れます。トークンにはシード済みの管理者のIDを入れる箇所があり、そこを合わせるだけでサーバーは正規の管理者と受け取ります。

成功すると、ユーザー・ロール・権限・データを扱うAPIをすべて操作されます。

CWEは1394（デフォルトの暗号鍵の使用）に分類されています。管理者のパスワードを破る必要がないので、強いパスワードや多要素認証を設けていても防げません。

筆者は、鍵が公開リポジトリから誰でも読める点から、公表後に試される可能性は高いと見ています。

攻撃の流れ

  1. 1

    鍵の入手

    公開されている配布物やソースから、固定のJWT署名鍵を手に入れます。

  2. 2

    トークン偽造

    手元で、管理者のIDを入れたトークンを署名して作ります。

  3. 3

    APIへ送信

    偽造したトークンを付けて、公開されているAPIにリクエストを送ります。

  4. 4

    管理者として受理

    サーバーが署名を正しいと判断し、管理者の権限を与えます。

  5. 5

    全面操作

    ユーザー・権限・データを読み書きされます。

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

どう悪用されるか

悪用に認証は要りません。APIにネットワークから到達できれば、利用者の操作も待たずに、攻撃者が単独で実行できます。CVSS v3のベクターもネットワーク経由・低い複雑さ・権限不要・操作不要を示しています。

トークンの署名は攻撃者の手元で完結するため、サーバー側のログイン失敗の記録には現れにくく、攻撃の予兆に気づきにくい点に注意が必要です。

成功すると管理者と同じ権限で、アカウントの作成や削除、権限の付け替え、保存データの閲覧と改ざんができます。機密性・完全性・可用性のすべてに高い影響が出ます。

今すぐやること

  1. 1

    3.6.1へ更新する

    ベンダーが公開した修正版3.6.1に更新します。更新前に設定ファイルをバックアップし、本番に当てる前にテスト環境で動作を確認してください。

  2. 2

    署名鍵を新しい値に入れ替える

    更新後は、推測されない長いランダムな値の署名鍵を自社で生成して設定します。古い鍵で作られたトークンはすべて無効になるため、既存のログインは切れます。設定値はリポジトリに置かず、環境変数やシークレット管理の仕組みで渡すと安全です。

  3. 3

    侵害の跡を調べる

    管理者の操作履歴で、身に覚えのないユーザー追加、ロールや権限の変更、データの大量取得や書き換えがないかを見ます。管理者トークンを使った通常と異なる時間帯・送信元IPからのアクセスも確認します。痕跡があれば、関係する認証情報や連携先の鍵も入れ替えてください。

  4. 4

    APIの公開範囲を絞る

    管理用のAPIは、社内ネットワークやVPN、許可したIPアドレスからだけ到達できるようにします。インターネットに直接出ている場合は優先して見直してください。

  5. 5

    ベンダーの告知を確認する

    リリースノートと修正のコミットで、鍵の扱いがどう変わったかを確かめます。独自に改修している場合は、同じ修正を自社のコードにも反映してください。

すぐ更新できないとき

すぐに更新できないときは、appsettings.jsonの署名鍵を自社で生成した推測されない値に変えて再起動し、APIの到達範囲をVPNや許可IPに絞ります。鍵を変えると既存トークンは無効になります。これは一時的なつなぎなので、できるだけ早く3.6.1に更新してください。

背景

ape-volo-adminは、.NETで作られたオープンソースの管理システムの基盤です。ユーザー・ロール・権限の管理やAPIの認証を最初から備え、社内の業務システムや管理画面の土台として取り込まれます。そのため、認証の仕組みに穴があると、その上に載るすべての機能が影響を受けます。

今回の問題は、配布物に含まれていた署名鍵を、そのまま使い続けられる状態にあったことです。JWTは署名鍵が漏れれば誰でも本物と区別できないトークンを作れるため、鍵を各環境で別々に生成して外から渡す運用が基本になります。公開リポジトリの設定に値が書かれていると、導入した組織が変え忘れた時点で、すべてが同じ鍵で動くことになります。

よくある質問

Q.強いパスワードや多要素認証を入れていれば防げますか。
A.防げません。攻撃者はログインの手順を踏まず、署名したトークンを直接送るためです。更新と署名鍵の入れ替えが必要です。
Q.更新後に、鍵を入れ替える必要はありますか。
A.あります。古い固定鍵はすでに公開されており、過去に偽造されたトークンが残っていれば有効なままになりかねません。自社で生成した新しい鍵に入れ替えて、既存トークンを無効にしてください。

まだ分かっていないこと

  • 実際に攻撃で悪用された事例の有無は、KEVへの掲載がなく確認されていません。

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

影響パッケージ

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

ape-volo-admin before 3.6.1 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge administrator tokens using a hardcoded JWT signing key in appsettings.json. Attackers can sign tokens offline with the jti claim set to the seeded administrator id to gain full API control over users, roles, permissions and data.

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

参照URL

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