BIツールは、社内のあらゆるデータベースへの接続情報が1か所に集まる場所である。にもかかわらず、情報システム部門の管理台帳に載っていないことが多い。
米CISAは2026年8月11日、MetabaseのSQLインジェクション脆弱性 CVE-2026-72898 をKnown Exploited Vulnerabilities（KEV）カタログへ追加した。是正期限として指定されたのは2026年8月14日。本日である。
追加から期限まで3日という設定は、KEVの中でも短い部類に入る。同じ8月11日に追加されたWindowsの脆弱性が14日間の猶予だったことと比べると、扱いの差は明らかである。
Metabase は、データベースに接続してダッシュボードやグラフを作成する、オープンソースのBI（ビジネスインテリジェンス）ツールである。売上、在庫、顧客、勤怠——業務の数字を見るために導入される。
そして本稿の主題は、この製品の脆弱性そのものではない。BIツールという種類のソフトが、なぜ管理から漏れ、なぜ漏れると影響が大きいのかである。
この記事を読むべき人
- Metabase、Redash、Supersetなどのオープンソースのダッシュボードツールを社内で使っている会社
- 経営企画やマーケティングの部署が、独自にデータ可視化ツールを立てている会社
- リモートワークのために、社内ツールを外部からアクセスできるようにしている会社
- BIツールを誰が管理しているか、即答できない経営者
- データ活用を進めたいが、セキュリティ面の整理が後回しになっている会社
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
何が起きるのか
Metabaseは2026年8月6日、公式のセキュリティアドバイザリ（GHSA-vwf4-m7j8-wcjf）を公開している。以下はその記載に基づく。
同アドバイザリによれば、認証を要しない /api/session/reset_password の処理を経由して、**遠隔の攻撃者が資格情報なしにアプリケーションのデータベースへ任意のSQLを注入し、管理者権限を取得できる。**その結果として、資格情報の窃取、設定の変更、データへの不正なアクセスと持ち出しが可能になるとされている。
CVSS基本値は 10.0 である。**CVSS v3.1の基本値の上限値にあたる。**認証も利用者の操作も不要で、攻撃の難易度も低く、機密性・完全性・可用性のすべてに最大の影響がある場合に付く数値である。
そして、Metabaseは同アドバイザリで悪用が実際に確認されていることを明記している。
**影響を受けるバージョンと修正版は複数の系列にまたがっており、本稿では個別のバージョン番号を再掲しない。**自社が使っている系列に対応する修正版を、上記の公式アドバイザリで直接確認する必要がある。
**🔴 即時に更新できない場合の暫定措置として、同アドバイザリは /api/session/reset_password エンドポイントを遮断することを挙げている。**これは公式に示された回避策であり、更新までの時間を稼ぐ手段になる。ただしパスワード再設定の機能が使えなくなるため、影響を確認したうえで実施する必要がある。
BIツールが持っているものを考える
技術的な深刻度以上に重要なのは、このツールが何を保持しているかである。
BIツールは、それ自体がデータを大量に持つわけではない。持っているのは、データがある場所への「鍵」である。
具体的には、次のような接続情報が設定として保存される。
- 販売管理・在庫管理などの業務データベースへの接続情報
- 顧客管理システムのデータベースへの接続情報
- 会計システムのデータへの接続情報
- 人事・勤怠データへの接続情報
- クラウド上のデータウェアハウスへの認証情報
**BIツールの価値は「複数のデータを1か所で見られること」にある。**その価値の源泉が、そのまま集中リスクになる。
管理者権限を取得されるということは、これらの接続先に対して、そのツールが持つ権限の範囲で操作できる状態になり得るということである。
**これは今回の事案で実際にそうした被害が確認されたという意味ではない。**ただし、BIツールの優先度を判断する際、「ダッシュボードが見られるだけ」という認識は実態と合っていない、という点は押さえておく必要がある。
なぜBIツールは管理台帳から漏れるのか
この種のツールが情報システム部門の把握から外れる理由は、導入の経緯にある。
理由1：導入するのが情報システム部門ではないことが多い。 BIツールを最初に必要とするのは、数字を見たい部署——経営企画、営業企画、マーケティング、経理である。オープンソースであれば費用も小さく、稟議を通さずに始められる。
理由2：「見るだけ」という認識で導入される。 データを書き換えるわけではないため、リスクが低いと認識されやすい。実際には、接続情報を保持している時点で、閲覧専用かどうかは別の論点になる。
理由3：便利さのために外部公開される。 在宅から数字を見たい、外出先で確認したい、という要望に応えて、インターネットからアクセスできるようにする。この判断自体は業務上の合理性があるが、公開したことが台帳に記録されない。
理由4：導入した担当者が異動・退職しても、ツールは動き続ける。 誰も止める理由がないため残る。そして、誰が管理者アカウントを持っているかが不明になる。
**この4つが重なると、「インターネットに公開されていて、社内の主要データベースへの接続情報を持ち、管理者が誰か分からないサーバ」が出来上がる。**そして今回のような脆弱性が公表される。
今日確認できること
大がかりな調査を始める前に、次の順で確認できる。
確認1：社内でBI・ダッシュボード系のツールが使われているか。 情報システム部門に聞くのではなく、数字を扱う部署に聞く。「グラフを自動で更新している画面はありますか」という聞き方のほうが、製品名を聞くより答えが返る。
確認2：それはどこで動いているか。 社内のサーバか、クラウドか、誰かのPCか。「誰かのPC」という答えが返ってくる場合もある。
確認3：インターネットから開けるか。 社外の回線から、URLを開いてみる。**ログイン画面が表示されれば、外部から到達できている。**これは技術知識がなくても確認できる。
確認4：どのデータベースに接続しているか。 管理画面の接続設定で確認できる。ここで、想定していなかった接続先が出てくることがある。
確認5：管理者アカウントを誰が持っているか。 退職者のアカウントが残っていないか。共有アカウントになっていないか。
**確認3までであれば、情報システムの専門知識がなくても実施できる。**そして、確認3で「開けた」となった場合、それだけで対応の優先度が決まる。
なお、確認1で「そういうツールは使っていない」という回答が返ってきた場合も、**そこで終わらせないほうがよい。表計算ソフトで作った集計表を自動更新している仕組みや、クラウドの分析サービスを部署単位で契約している例が、後から出てくることがある。「ダッシュボード」「BI」という言葉を知らないだけで、実質的に同じものを使っている場合がある。**聞き方を「数字を自動で集めている仕組み」に変えると、答えが変わることがある。
使っていないなら、止める
確認の結果、「以前は使っていたが、今は誰も見ていない」というツールが出てくることがある。この場合、最も確実で安価な対処は、止めることである。
止めることに抵抗が生まれるのは、「また使うかもしれない」「作ったダッシュボードが惜しい」という理由である。しかし、動かし続ける限り、脆弱性が出るたびに対応の判断が必要になる。
**判断の材料になるのは、直近のアクセスログである。**一定期間、誰も開いていないなら停止の候補になる。**ただし、期間の基準を機械的に決めてはいけない。四半期末や年度末にしか使わない集計、法定の保存期間に関わる帳票、他システムから自動で参照されている定期ジョブが存在することがある。「使われていない」と「まだ使われていない」は違う。**停止する前に、依存関係と社内の承認を確認したい。設定を書き出して保存しておけば、必要になったときに復元できる。
BIツールを使い続けるための最小構成
止めるという選択肢が取れない——実際に日常業務で使われている——場合に、最低限整えておきたい構成がある。大がかりな投資は不要で、設定の見直しで済むものが多い。
構成1：外部からの直接アクセスを閉じる。 社外から見たい場合は、VPNや社内ネットワーク経由に限定する。**BIツールの利用は「数字を確認する」用途が中心であり、即時性が求められる場面は少ない。**多少手間が増えても、実務への影響は小さいことが多い。
構成2：接続先データベースの権限を、閲覧のみに絞る。 BIツール専用のデータベースユーザーを作り、**必要なテーブルの参照権限だけを与える。**同じ接続情報で書き込みや削除ができる状態は、用途に対して過剰である。この設定は一度行えば以後は変わらない。
構成3：管理者アカウントを2名以上、かつ個人に紐づける。 共有アカウントは、誰が操作したかを追えなくする。**そして、必ず在籍者2名以上にしておく。**1名だと不在時に何もできず、0名だと今回のような案件で対処のしようがない。
構成4：更新の担当と、確認の時期を決める。 「気づいた人が更新する」は、誰も更新しないことと同義である。担当者と、定期的に確認する時期を決めてカレンダーに入れる。
⚠️ **ただし、定期確認は「悪用が確認された案件」には間に合わない。**今回のように、KEVの是正期限が3日という案件では、定期の周期がどれだけ短くても追いつかない。**定期確認とは別に、悪用確認済みの情報が入ったら即座に評価する経路を用意しておく必要がある。**この2つは役割が違う。
構成5：接続先の一覧を、ツールの外に記録する。 どのデータベースに繋いでいるかを、表計算などで別途持っておく。ツール自体にアクセスできない状況で影響範囲を判断する必要が生じたとき、この記録がないと何も分からない。
**この5つのうち、構成1と構成2は、多くの環境で効果が大きい。**いずれも設定変更で対応でき、追加の製品導入を伴わないことが多い。**着手の順序としては、この2つを先に検討したい。**ただし、接続先データベースの権限設計は既存の運用に影響し得るため、変更前に依存関係を確認する必要がある。
データ活用を進めるほど、この問題は大きくなる
最後に、経営判断としての論点を挙げる。
**データ活用を推進するということは、データが集まる場所を作るということである。**そして、集まる場所は、そのまま守るべき場所になる。
多くの会社で、この2つが別々に進む。**データ活用は事業部門の施策として、セキュリティは情報システム部門の課題として、それぞれ独立に扱われる。**結果として、データを集める仕組みは作られるが、その仕組み自体の守り方は誰も設計していない、という状態になる。
**実務的な対処は、「データ基盤を作るときに、管理責任者を1人決める」ことである。**技術的な対策の前に、責任の所在を決める。決まっていれば、脆弱性が出たときに誰が動くかが自明になる。決まっていなければ、情報が出ても誰も動かない。
今回のような是正期限3日の案件で差が出るのは、技術力ではなく、この一点である。
よくある質問
Q. Metabaseを使っていない。関係ないか。 A. 製品としては関係ない。**ただし、BIツールが接続情報を集約するという構造は製品を問わない。**別の製品を使っている場合も、公開範囲と管理者の確認は同じように必要である。
Q. 社内ネットワークからしか開けないなら安全か。 A. 外部から直接攻撃される可能性は大きく下がる。**ただし、別の経路で社内に侵入された場合、接続情報が集まっているBIツールは有力な次の標的になる。**優先順位としては後ろに置けるが、確認の対象から除いてよいという結論にはならない。
Q. クラウド版のサービスを使っている場合は。 A. 提供事業者が更新を管理する形であれば、利用者側の適用作業は不要な場合が多い。**確認すべきは、事業者が対応済みかどうかと、自社のアカウント権限の設定である。**特に、退職者のアカウントが有効なままになっていないかは、事業者側では判断できない。
Q. 接続先のデータベースの権限を絞れば、リスクは下がるか。 A. 下がる。**BIツールに与えるデータベースの権限を、閲覧に必要な範囲に限定しておくことは有効な対策である。**書き込み権限や、他のテーブルへの参照権限を持たせていないかを確認したい。ただし今回の脆弱性は、BIツール自身が使うデータベースが対象とされているため、接続先の権限設定だけでは完結しない。
Q. 現場が勝手にツールを立てるのを止めるべきか。 A. 禁止という形にすると、申告されないまま使われるだけになりやすい。**導入自体は妨げず、導入したことをどこかに登録させる運用のほうが実効性がある。**登録先は情報システムでも経理でもよく、集約先が1か所に決まっていることのほうが重要である。
Q. 誰も管理者アカウントを持っていないことが判明した。 A. 製品によっては、サーバへの直接のアクセス権があれば管理者を再作成できる場合がある。**それも困難であれば、現在のダッシュボードを作り直す前提で、管理された環境に立て直すほうが早い。**管理者不在のまま運用を続ける選択肢は避けたい。
Q. 是正期限が今日と言われても、間に合わない。 A. **本稿で触れている是正期限は、米国連邦政府機関を対象に設定された期日である。国内企業がこの日付に拘束されることはない。**間に合わないこと自体より、その間に外部から到達できる状態が続くかどうかが論点になる。**適用が難しいなら、一時的に外部からのアクセスを閉じるという選択肢がある。**BIツールは、業務を止めずに一時的に閉じやすい部類のシステムである。
データ基盤の設計と管理体制から相談したいとき
BIツールの導入は、データ活用の第一歩として合理的である。**問題は、導入の判断が事業部門で行われ、運用の責任が誰にも割り当てられないまま定着することにある。**この構造は、ツールを増やすほど広がる。
社内に分散しているデータの所在と、可視化ツールの利用状況を整理したい場合は、データ基盤・BI構築で対応している。公開範囲や接続権限の技術的な確認を含めたい場合は、公開範囲と接続権限を確認するが該当する。
データ活用の全体像を設計し直したい段階であればデータ活用の全体像を設計し直す、現在のツール構成が自社の規模に合っているか第三者の視点で確認したい場合は現在のツール構成が規模に合うか確認するから相談できる。
なお、BIツールの製品選定そのものはMetabase・Superset・RedashのOSSとSaaSの比較、導入手順はBIダッシュボード導入ガイドで扱っている。本日が期限という点で並んでいる本日が期限のCisco ASA/FTD案件は、ネットワーク機器側の案件になる。本稿は、BI・データ基盤の露出と管理責任に絞っている。
参照した情報
- CISA Known Exploited Vulnerabilities Catalog（JSON配信）: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Metabase 公式セキュリティアドバイザリ GHSA-vwf4-m7j8-wcjf: https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf
- Metabase: https://www.metabase.com/
CVE-2026-72898のKEVカタログへの追加日（2026年8月11日）、是正期限（2026年8月14日）、登録名「Metabase SQL Injection Vulnerability」、対象製品、および同日追加のCVE-2026-68820の是正期限が2026年8月25日である旨については、KEVカタログのJSON配信（カタログバージョン2026.08.11）を参照した。
アドバイザリの公開日（2026年8月6日）、脆弱性の内容（認証を必要としない /api/session/reset_password エンドポイント経由でアプリケーションのデータベースへ任意のSQLを注入し管理者権限を取得できる点）、そこから生じ得る影響（資格情報の窃取、設定の変更、データへの不正なアクセスと持ち出し）、CVSS基本値10.0、悪用が実際に確認されている旨、および暫定的な回避策として当該エンドポイントの遮断が示されている旨は、いずれも上記Metabaseの公式セキュリティアドバイザリの記載による（2026年8月14日に取得）。
**影響を受けるバージョンと修正版の番号は、本稿にはあえて書いていない。**系列ごとに修正版が分かれているうえ、公開されている情報源によって影響範囲の記載に差があるためである。**転記を一段挟むだけで適用対象を取り違える。**上記の公式アドバイザリで直接確認してほしい。
**BIツールが保持する接続情報の集中によって影響範囲が広がり得るという指摘は、GXOによる一般的なリスクの整理である。**公式アドバイザリは資格情報の窃取が生じ得ることを述べているが、個々の環境で接続先にどこまで到達され得るかは構成に依存する。管理台帳から漏れる4つの理由、5つの確認手順、停止を判断する際の考え方、使い続けるための最小構成5点、そして管理責任者を1人決めるという提案。これらはすべてGXO側の実務整理であって、MetabaseやCISAが示した基準ではない。実際の攻撃手順、どの程度の範囲で悪用が観測されているか、および自社環境が該当するかの判定方法は、本稿の対象外である。前述のとおり、KEVカタログの期日は米国連邦政府機関向けの指定であり、国内企業への法的効力を持つものではない。
