JPCERTがMetabase悪用とWebシェル設置を追記｜更新後に必要な侵害確認

JPCERT/CCは2026年10月23日、国内組織で相次ぐ不正アクセスに関する注意喚起を更新し、MetabaseのSQLインジェクション脆弱性CVE-2026-72898を悪用したアクセスの痕跡と、公開Webサーバーから到達可能なアプリケーションサーバーへ悪性WARファイルが置かれた事例を追記しました。どちらもWeb運営者が確認すべき重要な情報ですが、JPCERT/CCは複数の事案をケース別に整理しており、二つが同一の侵入で連続して発生したとは説明していません。

今回の更新で実務上の判断が変わる点は、既知の脆弱性を修正するだけでなく、過去のアクセスログと内部サーバーの配置物を調べる具体的な手掛かりが増えたことです。Metabaseの修正版は8月に公開済みですが、公開エンドポイントが影響を受ける状態だった環境では、現在の版が安全でも過去の侵害を否定できません。この記事では10月23日の追記を基に、更新、痕跡確認、資格情報の見直し、横展開調査を分けて進める手順を整理します。

10月23日の追記で確認できる新事実

JPCERT/CCの更新版注意喚起は、ケースCとしてMetabaseのCVE-2026-72898を挙げ、8月上旬から9月上旬までの間に悪用された不審な送信元IPアドレスを3件、User-Agentの例を2件掲載しました。これは8月14日の製品別注意喚起に、国内の調査で参照できる観測情報を加えた続報です。

同じ更新のケースDでは、公開Webサーバーからアクセス可能なアプリケーションサーバー上にWARファイルが設置され、その中のJSPファイルが簡易Webシェルとして動作した事案を説明しています。Webシェルは特定のクエリパラメーターをシェルコマンドとして実行する機能を持ち、9月ごろには特定の送信元からGETとPOSTによる繰り返しアクセスが確認されました。

掲載されたIPアドレスやUser-Agentは、侵害を断定するための一致条件ではありません。JPCERT/CC自身も、調査時点で正規利用されている可能性や、掲載期間外・別のアクセス元で攻撃が試行された可能性を注記しています。IPだけで遮断や安全宣言を行わず、対象URL、時刻、応答コード、前後のリクエスト、作成されたアカウントやファイルと組み合わせて評価します。

Metabaseは認証なしで管理者権限へ至る可能性

Metabaseが2026年8月6日に公開したGitHub Security Advisory GHSA-vwf4-m7j8-wcjfは、CVE-2026-72898をCritical、CVSS 3.1で10.0と評価しています。認証されていない遠隔の攻撃者がMetabaseのアプリケーションデータベースへ任意のSQLを注入し、管理者権限を取得する可能性があります。そこから設定変更、接続先データベースの保存済み認証情報の窃取、接続権限で読めるデータの閲覧や出力へ影響が広がり得ます。Metabaseは実環境での悪用を確認済みとしています。

Metabaseの公式セキュリティ更新が示す最低安全版は、0.63.5、0.62.9、0.61.11、0.60.17、0.59.21、0.58.24です。58系より前は今回の脆弱性の影響を受けないとされ、Metabase Cloudは対策済みです。セルフホスト環境は、自分が使う系列に対応する安全版以上へ更新します。コンテナではタグの見た目だけでなく、再展開後に稼働しているイメージとアプリケーションの版を確認してください。

直ちに更新できない場合、Metabaseは/api/session/reset_passwordへのアクセス遮断を一時的な回避策として案内しています。ただしこれは影響経路を一時的に閉じる措置であり、修正や侵害調査の代わりにはなりません。過去に当該エンドポイントがインターネットから到達できたなら、遮断後や更新後も調査を続けます。

更新と侵害確認を二つの作業に分ける

最初に現在の露出を抑えます。外部公開が不要なMetabaseはVPN、許可IP、認証付きリバースプロキシなど既存の管理境界へ戻し、影響するエンドポイントを公開したまま調査しないようにします。同時に、Web・リバースプロキシ・ロードバランサー・WAF・Metabase・アプリケーションデータベース・接続先データベースのログを、保持期間を確認したうえで別領域へ保全します。時刻同期とタイムゾーンも記録し、異なる機器のイベントを誤って並べないようにします。

次に修正版を適用し、再起動または再展開後の稼働版を記録します。更新前後のアーティファクト、コンテナdigest、設定、プロセス起動時刻を残し、旧インスタンスや古いPodがトラフィックを受けていないか確認します。資産確定から段階反映、稼働版の検証までの共通手順は「緊急パッチを安全に適用する実務ランブック｜資産確認からロールバックまで」で詳しく整理しています。

調査は更新完了と別の完了条件を持たせます。Metabaseが示す特徴的な並びは、POST /api/session/reset_passwordがHTTP 400を返した後に、GET /api/user/currentがHTTP 200を返すアクセスです。この連続がログにあれば、Metabaseは侵害の可能性が高いとしています。ただしログ欠落や別経路を考慮し、この並びがないことだけで未侵害とは断定しません。

Metabaseで優先して確認する六つの項目

1. 公開履歴：影響期間に/api/session/reset_passwordが外部から到達可能だったか、WAFやプロキシで転送されていたかを構成履歴から確認する。
2. アクセスの連続性：公式が示すPOST 400とGET 200の並び、JPCERT/CC掲載の観測情報、同一セッションや近接時刻の追加API呼び出しを検索する。
3. 管理者とセッション：不明な管理者、権限変更、想定外のログインを確認し、Metabase公式手順に従って全アクティブセッションを無効化する。
4. APIキー：発行者、作成時刻、最終利用、権限を照合し、不明なキーを削除する。侵害が疑われるキーは利用先ログも追う。
5. 接続先データベース：保存されていた認証情報を変更し、データウェアハウスの監査ログで不審な参照、出力、権限変更を調べる。
6. アプリ内履歴：Metabaseのアクティビティとクエリー履歴、設定変更、データ出力を確認し、業務上の操作と照合する。

資格情報の変更は順序が重要です。証拠保全前に一斉変更すると、攻撃者のセッション切断には役立つ一方で、調査対象の時刻や利用状況が分かりにくくなる場合があります。公開制限とログ保全を先に行い、侵害の可能性が高い場合は、管理者セッション、APIキー、接続先データベースの認証情報を優先して失効・再発行します。変更後は古い資格情報がアプリ、バッチ、バックアップ設定に残っていないかを確認します。

Webシェル事例は内部サーバーまで調査範囲を広げる

ケースDが示す重要な点は、外部から直接見えるWebサーバーだけを調べても不十分な場合があることです。公開Webサーバーからアプリケーションサーバーへ通信でき、後者にWARを配置・展開できる経路があれば、攻撃者は境界の内側へ実行機能を残せます。Webサーバーを再構築しても、内部側のWebシェルや資格情報が残れば再侵入される可能性があります。

TomcatなどWARを扱うアプリケーションサーバーでは、デプロイディレクトリ、展開済みディレクトリ、テンポラリ領域、サービス定義、起動オプションを確認します。未知のWAR・JSP、平時と異なる作成者や更新時刻、短い難読化コード、外部入力をコマンド実行へ渡す処理、想定外の子プロセスを探し、ファイルは削除前にハッシュとメタデータを保存します。EDR、OS監査、Webアクセス、アプリケーションログを同じ時系列に並べ、ファイル配置、展開、Webシェルへのアクセス、その後のコマンド実行や外向き通信を関連付けます。

さらに、公開Web層からアプリ層へ許可されるポートとアカウントを棚卸しします。アプリの配置権限をWeb層のサービスアカウントが持つ必要があるか、管理ポートが公開系から到達できる必要があるか、共有秘密やSSH鍵が置かれていないかを確認します。JPCERT/CCも、Webサーバー侵害後の横展開対策、不正アクセス検知と初動、不要な管理機能のインターネット公開停止を推奨しています。

IOC一致だけで終わらせない検証

公開されたIPアドレスやUser-Agentは、過去ログを絞り込む入口として使います。一致した場合は、対象URL、HTTPメソッド、応答、送受信量、セッション、直後の操作、同じ時間帯のファイル変更を確認します。一致しない場合も、エンドポイント別の異常な400と200、管理者作成、APIキー発行、設定変更、DBへの大量アクセス、アプリサーバーの新規WAR・JSPを行動ベースで調べます。

また、10月23日のJPCERT/CC更新はAIを用いたペネトレーションテスト基盤の悪用試行も別ケースとして追記していますが、MetabaseやWebシェルの各事例がAIによる攻撃だったとは説明していません。根拠のない関連付けはせず、確認できた攻撃経路と痕跡に基づいて対応します。管理APIの認可とトークン運用を点検する共通手順は「国内の不正アクセス注意喚起を踏まえた管理APIの認可と点検手順」も参照してください。同記事は10月初旬の確認時点に基づくため、今回の追加IOCは本記事と最新のJPCERT/CC資料で補ってください。

今回の続報は、修正版公開から時間がたった脆弱性でも、国内の観測情報が追加されれば調査優先度が変わることを示しています。セルフホストのMetabaseは安全版への更新だけでなく、公開履歴と侵害痕跡を確認してください。Web層から内部アプリ層へ到達できる構成では、WAR・JSP、実行プロセス、資格情報、接続ログまで範囲を広げます。対応完了は「最新版」と表示された時点ではなく、過去の侵害可能性を評価し、残存物と横展開経路を処置した時点です。

関連記事

• 緊急パッチを安全に適用する実務ランブック｜資産確認からロールバックまで
• 国内の不正アクセス注意喚起を踏まえた管理APIの認可と点検手順