Jpomに認証回避の脆弱性、管理者権限を奪われる恐れ
Jpom 2.10.0から2.11.12に、ログインなしでスーパー管理者の権限を得られる脆弱性が公表されました。Jpomを使う組織は、版と到達範囲を調べ、修正版の有無を確認して更新してください。
急ぎ度: 至急
CVSS v3は9.8、v4は9.3で、認証もユーザー操作も要らずネットワーク越しにコマンド実行まで到達できるため、外部から届く環境では早い対応が要ります。
関係があるか
Jpom 2.10.0から2.11.12を、ビルドやデプロイ、プロセス管理の運用基盤として動かしている組織が対象です。管理画面がインターネットや広い社内ネットワークから届く環境ほど危険です。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Jpom（dromara） | 2.10.0以上、2.11.12以下 | 2.11.12より新しい版が出ているかを、プロジェクトのリリース情報とセキュリティ告知で確認してください |
確かめ方
- 1Jpomの管理画面か、サーバー上の配布ファイル名で版を確認します。2.10.0から2.11.12の範囲なら対象です。
- 2管理画面のポートが、インターネットや利用者ネットワークから届くかを、ファイアウォールとリバースプロキシの設定で確認します。
- 3検証用や部署ごとに立てた、情シスが把握していないJpomが残っていないかも探します。
何が起きたか
Jpomに、ログインしていない人が最高権限のスーパー管理者として操作できてしまう脆弱性が見つかりました。管理者になれば、Jpomのスクリプト機能を通じてサーバー上でコマンドを実行されます。
2026年10月31日に公表された脆弱性です。原因は、リクエストのJPOM-USER-TOKENヘッダーに入れた値を、認証の確認で検索条件として解釈してしまう点にあります。値は本来トークンとして照合されるべきですが、JavaのユーティリティライブラリHutoolの条件解析が、値の一部を演算子として扱います。その結果、正しいトークンを持たなくても認証を通過します。分類はCWE-943です。
影響するのは2.10.0から2.11.12です。
攻撃の流れ
-
1
管理画面に到達
Jpomサーバーにネットワーク経由で接続できる位置から始まります。
-
2
細工したヘッダー
JPOM-USER-TOKENヘッダーに、トークンではなく検索条件として解釈される値を入れて送ります。
-
3
認証をすり抜け
照合が成立したと判断され、スーパー管理者として扱われます。
-
4
コマンド実行
スクリプト機能を使い、Jpomが動くサーバー上でコマンドが実行されます。
どう悪用されるか
認証は要りません。攻撃者はJpomの管理画面にネットワークから届けば足り、アカウントも利用者の操作も必要としません。攻撃の難易度は低く、CVSSのベクターでも、ネットワーク経由・特別な条件なし・権限不要・操作不要と評価されています。
成功すると、Jpomのスーパー管理者としてすべての機能を使えます。スクリプト機能から任意のコマンドを実行されるため、機密性・完全性・可用性のすべてに高い影響が出ます。Jpomに登録された接続情報やスクリプトの内容が読まれたり、書き換えられたりすることも考えておくべきです。
今すぐやること
-
1
Jpomの稼働台数と版を洗い出す
本番だけでなく、検証用や個人が立てたものも含めて、2.10.0から2.11.12が動いていないかを一覧にします。
find / -iname "jpom*" 2>/dev/null -
2
修正版を確認して更新する
ベンダーの告知とGitHubのリリース情報で、2.11.12より新しい修正版が出ているかを確認します。出ていれば、検証したうえで速やかに更新します。更新前にデータと設定のバックアップを取ります。
-
3
管理画面への到達範囲を絞る
インターネットから直接届く状態なら、まず遮断します。社内でも、運用担当者のネットワークや踏み台だけに限定します。
-
4
侵害の跡を調べる
公表直後で、実際の悪用の有無はまだ見えていません。Jpomとリバースプロキシのアクセスログで、不審な接続元や不自然なヘッダー値のリクエストを探します。あわせて、身に覚えのないスクリプトの作成・実行、ユーザーの追加、設定変更がないかを確認します。
-
5
登録情報の見直し
不審な操作が見つかった場合は、Jpomに登録していた認証情報や鍵を作り直します。Jpomが管理していたサーバー側も、あわせて点検します。
修正版がないあいだのつなぎ
修正版をすぐ当てられないときは、ファイアウォールやセキュリティグループで、Jpomの管理画面に接続できる送信元を運用担当者のIPアドレスだけに限定します。外部公開が必要な場合は、VPNの内側に置いてください。この対策は到達できる相手を減らすだけで、脆弱性そのものは残ります。更新までのつなぎとして使います。
背景
Jpomは、Javaで作られたオープンソースの運用管理ツールで、dromaraプロジェクトが公開しています。サーバー上のプロジェクトのビルドやデプロイ、プロセスの起動と停止、ログの閲覧、スクリプトの実行を、ブラウザーの管理画面からまとめて行うために使われます。
この性格のため、管理画面を突破されると、画面操作の範囲にとどまらず、スクリプト機能を通じてサーバー上の実行権限そのものを握られます。今回は認証の照合が検索条件の評価に委ねられていた点が問題で、トークンの値が正しいかどうかではなく、条件式が成立するかどうかで通過が決まっていました。認証にデータベース風の条件式を使う実装は、入力値の扱いを誤ると、パスワードを知らなくても通れる穴になります。
よくある質問
Q.管理者パスワードを強くすれば防げますか。
Q.Hutoolを使っている自社のアプリも影響を受けますか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 修正版 |
|---|---|---|---|
| dromara | Jpom |
2.10.0 〜 2.11.12 |
— |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Jpom 2.10.0 through 2.11.12 contains an authentication bypass vulnerability that allows unauthenticated attackers to gain super-administrator access by injecting query conditions into the JPOM-USER-TOKEN header. Attackers can send a value like 'is not null', which Hutool's Condition parser treats as an operator, then execute commands through Jpom's script features.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- web github.com
- web github.com
- web github.com
- web vulncheck.com
- web nvd.nist.gov
- web github.com