MetabaseのSQLインジェクション0-dayが顧客データ盗難に悪用—Framework・Tallyが被害を公表
データ分析ツールMetabaseのゼロデイSQLi脆弱性が実際の攻撃に利用されたことが判明。BIツール経由で顧客データが窃取される新たな攻撃パターンに注意が必要だ。
喜村 圭佑(編集責任者)更新 約6分

THREAT GAUGE3つの指標でこのインシデントの脅威度を評価しています。IMPACT(影響範囲)は被害の大きさ、URGENCY(対応緊急度)は対応までに残された時間の短さ、EXPLOIT(悪用の容易さ)は攻撃者が実際に悪用できる容易さを表します。算出基準
“実際の攻撃での悪用が確認済み。詳細なPoC有無は調査継続中。”
01 · Overview
ニュースの概要
2026年8月7日(現地時間)、データ分析ツール「Metabase」にクリティカルなSQLインジェクションのゼロデイ脆弱性が存在し、Framework(PC・電子機器メーカー)とTally(ビジネスソフトウェア企業)の顧客データが盗難被害を受けたことが公表されました。攻撃はMetabaseのセルフホスト型インスタンスを標的に行われたものとみられています。
BleepingComputerの報道によれば、攻撃者はMetabaseのSQLインジェクション脆弱性を悪用して対象組織のMetabaseインスタンスに侵入し、接続されたデータベースから顧客情報を窃取しました。ゼロデイ脆弱性として悪用されたことから、パッチが存在しない状態で攻撃が行われたことになります。
Metabaseはオープンソースおよびクラウド型のビジネスインテリジェンス(BI)・データ分析プラットフォームで、スタートアップから中堅企業まで広く使われています。日本国内でも採用事例が多く、セルフホスト環境での運用が一般的です。今回の攻撃はBIツールを踏み台にした顧客データ搾取という新たな攻撃パターンとして注目されます。
MetabaseはBIツールの性質上、社内の複数のデータベースやデータウェアハウスに接続されているケースが多く、一度侵入されると組織の重要データの大半にアクセスできる可能性があります。Metabaseインスタンスへの不審なクエリ・アクセスログを確認するとともに、最新パッチへの更新を急いでください。
- 脆弱性種別
- SQLインジェクション(ゼロデイ)
- 影響を受けた組織
- Framework・Tally(確認済み)
- 被害内容
- 顧客データ窃取
- 攻撃確認日
- 2026年8月7日公表
- 対象
- Metabaseセルフホスト型インスタンス
BleepingComputer報道(2026-08-07)を参照。Metabase公式の詳細アドバイザリは調査継続中のため、最新情報を随時確認してください。
02 · Analysis
詳細な原因解説
今回の攻撃は、MetabaseのクエリエンジンにおけるSQLインジェクション脆弱性を悪用したものです。SQLインジェクションとは、アプリケーションがユーザー入力を適切にサニタイズせずにSQLクエリへ組み込む場合に発生する古典的だが依然として危険な脆弱性です。攻撃者は細工したSQLクエリをMetabaseのAPIやUIを経由して送り込み、接続先データベースから任意のデータを引き出すことができます。
BIツールが攻撃ベクトルとして標的になる点が今回の事案の重要な特徴です。MetabaseのようなBIツールは、データベースの読み取り権限を持つ専用の接続情報(サービスアカウント)を使って複数のデータソースに接続されています。多くの組織ではBIツールへのアクセスは「社内向け」として扱われがちで、インターネットから直接アクセス可能な状態で放置されているケースも少なくありません。
ゼロデイ脆弱性として悪用されたという事実は、ベンダーが修正パッチを提供する前から攻撃が行われたことを意味します。今後、Metabaseが正式なセキュリティアドバイザリと修正バージョンを公開することが予想されますが、それまでの間は緩和策(ネットワーク分離・アクセス制限)による防御が重要になります。
Metabaseはオープンソースでありソースコードが公開されているため、研究者や攻撃者がコードを精査して類似の脆弱性を発見するハードルが相対的に低いという側面があります。同種のBIツール(Redash、Apache Superset等)にも同様のリスクがないかを横断的に確認することが求められます。
03 · Action
今からできる主な対策
明日からすぐ
1週間以内
05 · Forecast
今後起こりうる展開と対策複数の思考フレームワークを用いて、今後起こりうる展開と有効な対策を整理したセクションです。
SCAMPER分析:BIツール攻撃の応用・発展予測
Q. BIツールへのSQLインジェクション攻撃が「組み合わせ・応用」されるとどのようなリスクに発展するか?
【Combine(組み合わせ)】BIツールはデータウェアハウスと連携していることが多く、S3・BigQuery・Snowflake等への接続認証情報が読み取られた場合、クラウドデータレイク全体への横展開攻撃が発生しやすい。 【Adapt(適用)】MetabaseはOSSであるため、同様の手法をRedash・Apache Supersetへ転用することが容易。今後2週間以内にこれらツールへのスキャン攻撃増加が予想される。 【Substitute(代替)】BIツール経由のデータ搾取が「直接DBへの不正アクセス」の代替手段として確立されると、EDRが検知しにくい「正規ツール経由のデータ流出」として高度化する恐れがある。 【Eliminate(除去)】BIツールの「インターネット公開」という設計要素を廃止し、VPN専用アクセスとする構成変更が最も効果的な緩和策。
システム思考:BIツールという「信頼された攻撃経路」
Q. 組織内でBIツールが持つ「過剰な信頼」はなぜ生まれ、どのように是正できるか?
BIツールは「データを見るだけのツール」という認識から、セキュリティレビューが甘くなりがちです。しかし実態としてはBIツールは組織の全データソースへの「マスターキー」に近い存在であり、侵害時の影響範囲は本番DBへの直接侵入と同等かそれ以上になり得ます。 システム構造として、BIツール→本番DB→顧客データというデータフローに対して、セキュリティ管理(アクセス制御・ログ・最小権限)が後付けになっていることが多い。これは「利便性を優先した設計」の遅延コストが今回のような形で顕在化したものです。 フィードバックループとして、BIツールへの不正アクセスが発覚しにくいのは「通常業務としてのデータクエリ」と「攻撃クエリ」の区別が難しいためです。行動ベースの異常検知(ベースラインからの逸脱検知)の導入が中長期的な解決策となります。
BIツールへの即効性のある防衛策
最優先事項はMetabaseインスタンスのインターネット公開状況の確認とネットワークレベルでのアクセス制限です。VPNまたはゼロトラストアーキテクチャ(Cloudflare Access等)を経由しないとアクセスできない構成にすることで、外部からの攻撃経路を大幅に削減できます。
Metabaseのデータベース接続に使用するサービスアカウントの権限を最小化(読み取り専用・必要テーブルのみ)することで、万が一侵入されても被害範囲を限定できます。BIツールが更新権限を必要とするケースはほとんどないため、書き込み権限は原則として付与しないでください。
06 · AI Prompt
AI対策プロンプトこのニュースを踏まえて自組織の対策を検討する際に、そのままAIアシスタントへ入力できるプロンプトのテンプレートです。
あなたはサイバーセキュリティの専門家です。 【背景情報】 データ分析ツール「Metabase」にSQLインジェクションのゼロデイ脆弱性が発見され、実際の攻撃で顧客データが盗難される被害が複数組織で発生しました。BIツールを経由したデータ搾取という攻撃パターンです。 【あなたの組織情報】 - 組織名・業種:[組織名・業種] - Metabaseの利用有無・バージョン:[利用しているバージョンまたはNone] - 類似BIツールの利用状況:[利用中ツール名またはNone] - データベースの種別と扱う個人情報の概要:[DB種別・個人情報の有無] - セキュリティ担当者体制:[体制] 上記情報をもとに、以下を出力してください: 1. 自組織での影響範囲の評価と確認手順 2. 即時実施すべきネットワーク制限・権限最小化の具体的な設定手順 3. ログ調査で確認すべき不審なSQLパターン(例示付き) 4. 類似BIツールへの横断チェックリスト
キーワード
- Metabase
- SQLインジェクション
- ゼロデイ
- BIツール
- データ流出
SOURCES · 参考情報源
- Metabase SQLi zero-day exploited in customer data-theft attacks ↗— BleepingComputer(2026-08-07)
- Metabase Security Updates ↗— Metabase



