Metabaseに危険度10.0の脆弱性で顧客情報流出 CVE-2026-72898、即更新を

会社のデータを集計してグラフや表にする人気ツール「Metabase（メタベース）」に、ログインもパスワードも一切必要とせず、外部から管理者になりすませる欠陥が見つかりました。識別番号はCVE-2026-72898、危険度は10点満点の10.0です。しかもこれは「見つかってから直った」話ではありません。修正版が存在しない状態のまま実際の攻撃に使われ、被害が出た後で公表されました。

被害はすでに表に出ています。修理しやすいノートパソコンで知られるメーカーFrameworkは、8月7日に「全顧客」に向けて氏名・住所・電話番号・メールアドレス・ログイン時のIPアドレスが閲覧されたと通知しました（TechCrunch）。業務自動化ツールのn8n、フォーム作成サービスのTally、AIコーディング支援のKilo Codeなども相次いで公表しています。いずれも自社のシステムが破られたのではなく、社内の集計に使っていたMetabaseが入口になったという共通点があります。

米国土安全保障省傘下のCISAは8月11日、この欠陥を「実際に攻撃が確認された脆弱性リスト」に登録し、政府機関に8月14日までの対処を命じました（このリストの最新の登録状況はこちらでも追えます）。Metabaseのクラウド版を使っている場合は運営側で修正済みですが、自社サーバーやDockerで動かしている場合は自分で更新するしかありません。対象は1.58系以降のすべてで、上げるべき版は本記事の表にまとめました。

そもそもMetabaseとは何か

Metabaseは、社内にたまっている売上や会員などのデータをつないで、プログラミングなしでグラフや一覧表を作れる「BIツール」と呼ばれるサービスです。BIはビジネス・インテリジェンスの略で、要はデータを見やすく可視化して経営や現場の判断に使う道具のことです。2015年に登場したオープンソースソフトで、世界で約5万社が利用しているとされ、「5分で入れられて、社員全員が使える」手軽さから、エンジニアのいるスタートアップから大企業の一部門まで幅広く導入されています。

Metabaseは社内の本番データベースに直接つないで動きます。売上管理システム、顧客管理システム、在庫データなど、会社の中核データにアクセスできる「窓口」として設置されます。つまりMetabaseのサーバーそのものを乗っ取られると、攻撃者はそこにつながったすべてのデータベースの接続情報（ユーザー名やパスワード）にまで手が届くことになります。ただの分析ツールに見えて、実は会社のデータの中心に置かれた鍵束のような存在なのです。

今回のFrameworkやn8nの一件が「自社は攻撃されていないのに顧客情報が出た」形になったのは、この構造そのものが理由です。商品データベースや会員システムを厳重に守っていても、その数字を眺めるために置いた画面が外を向いていれば、そこから同じデータに手が届いてしまいます。社内向けの便利ツールが会社全体への入口に変わる事故は過去にも起きており、ローコード開発基盤Appsmithの通信の出入り口を乗っ取られる脆弱性もその一例です。

CVE-2026-72898で実際に何が盗まれたのか

今回のCVE-2026-72898がこれまでのMetabaseの脆弱性と決定的に違うのは、「起こり得る」ではなく「もう起きた」段階で公表されたことです。攻撃者は8月2日から3日にかけて、まだ誰も知らなかったこの穴を使ってMetabaseのクラウド基盤に入り込み、そこに乗っている各社の環境から顧客データを抜き出しました。Metabase自身が異変に気づいたのが8月3日、利用企業への通知が8月6日です。企業側は自分で気づく術がなく、通知を受け取って初めて知りました。

Framework：全顧客に「あなたも対象です」と通知

最も大きく報じられたのがFrameworkです。パーツ単位で交換・修理できるノートパソコンを作る米国のメーカーで、修理する権利を掲げる姿勢から技術者層に強い支持があります。同社は8月6日にMetabaseから連絡を受けた当日、接続していたデータベースの認証情報をすべて入れ替えたうえで、翌7日に全顧客へメールで通知しました。

閲覧されたのは、氏名・メールアドレス・住所・電話番号・ログイン時のIPアドレスです。法人顧客の場合は、これに会社名・付加価値税番号や納税者番号・請求先メールアドレスが加わります。一方でクレジットカードなどの決済情報と注文履歴は含まれていないと同社は説明しています（The Register）。金銭が直接抜かれる種類の流出ではありませんが、住所と電話番号がそろっているため、購入者を装った詐欺メールや電話の材料としては十分です。

n8n：136件、うち5件はパスワードのハッシュ付き

業務の流れを画面上でつないで自動化するツールn8nは、社内分析にMetabaseを使っていました。同社は8月8日に第一報を出し、11日に詳細な調査結果を公表しています。閲覧されたのは氏名とメールアドレスを含む136件で、内訳は「クラウド版の利用者名とメールが7件」「氏名・利用者名・メール・暗号化済みパスワードが5件」「氏名とメールのみで閲覧を確定できなかったものが62件」「機微な情報を含まないものが62件」です。

件数だけ見れば小さく思えますが、n8nはこの調査の過程で過去の不具合により約25件のパスワードが暗号化されずそのまま保存されていたことも見つけ、あわせて公表しました。今回の攻撃でそれが読まれた可能性は低いとしていますが、事故調査が別の問題をあぶり出した形です。同社はベルリンの個人情報保護当局にも届け出たうえで、該当者に個別メールでパスワード変更を求めています。被害が小さくても内訳まで開示する姿勢は、国内企業の公表文と読み比べる価値があります。

Tally・Kilo Code・Checkly も相次いで公表

フォーム作成サービスのTallyは8月7日、メールアドレスと暗号化済みパスワードが閲覧されたと発表しました。ただし「フォームそのものや、回答者が送信した内容には届いていない」と明言しています（BleepingComputer）。AIコーディング支援のKilo Codeを運営するAnacondaは、8月2日の約4時間という侵入時間まで特定したうえで、一部利用者のSlack連携用トークンが露出したと公表しました。監視サービスのCheckly も8月10日に続いています。

共通しているのは、いずれも「自社の本番システムは破られていない」という点です。攻撃者が触れたのは分析用に集められたデータのほうでした。とはいえ、分析用に集めたデータには氏名とメールアドレスがほぼ確実に入っています。本番データベースを厳重に守っていても、その写しを置いた分析基盤が同じ強度で守られていなければ意味がないという現実が、5社の公表文からそろって読み取れます。

誰がこの穴を狙い、何が起きるのか

この穴を最初に使ったのが誰なのかは、まだ公表されていません。ただ動き方を見ると、狙っていたのは企業の顧客名簿を持ち出して売り買いする、データ窃取を専門とする集団と考えるのが自然です。侵入から持ち出しまでが数時間で終わっており、サーバーを壊すでも身代金を要求するでもなく、名前とメールアドレスの入った表だけを持って引き上げているからです。

やっていることは、拍子抜けするほど単純です。パスワードを忘れた人のために誰でも触れるようになっているパスワード再設定の受付窓口へ、細工した文字列を1回送りつけるだけ。それだけで管理者としてログインした状態が手に入ります。あとは管理画面から、Metabaseにつないである各データベースの接続情報を読み取り、そこに入っている顧客一覧を画面上で書き出して持ち帰る。攻撃者から見れば、鍵のかかった金庫を破るのではなく、金庫の中身を毎朝コピーして机に並べてくれる係の人に近づくようなものです。

この結果、サービスを使っている一般の人が失うのは、氏名・メールアドレス・住所・電話番号といった、詐欺の材料としてそのまま使える情報です。「先日ご購入いただいた商品について」と自分の本名と住所を正確に書いた連絡が届けば、多くの人は疑いません。一方、システムを運用する側が失うのは情報そのものだけではありません。Metabaseにつないでいたデータベースの接続情報が抜かれている以上、被害がMetabase単体で止まった保証はないという状態から調査を始めることになります。Frameworkが通知を受けたその日のうちに全認証情報を入れ替えたのは、この線を断つためです。自社で同じ判断が必要になるかどうかの見分け方は、後半の「侵入された形跡の見つけ方」にまとめました。

技術的に見ると何が起きているのか

Metabaseにはこの2か月で、経路の異なるサーバー乗っ取りの欠陥が4件公表されました。最も重いのが今回のCVE-2026-72898で、これだけがアカウントを一切必要としません。残る3件は何らかのログイン権限が前提になります。新しいものから順に見ていきます。

CVE-2026-72898：パスワード再設定の窓口にSQLを流し込まれる

舞台は POST /api/session/reset_password という受付窓口です。パスワードを忘れた人がメールで受け取った合言葉（トークン）と新しいパスワードを送る場所で、性質上ログインしていない人でも触れるように公開されています。本来ここが受け取ってよいのは、その2つだけでした。

ところがMetabaseの処理は、送られてきたデータに余計な項目が混ざっていても、それを捨てずにそのまま持ち回っていました。セキュリティ企業Wizの解析によれば、攻撃者は本来送るべき2項目に加えて、利用者を指す内部項目を自分で捏造して送り込みます。Metabaseが内部で使っているClojureというプログラミング言語には、複数のデータをまとめる際に知らない項目を素通りさせる性質があり、捏造された項目はそのまま奥へ流れていきました。

最後の関門が、データベースへの問い合わせ文を組み立てる部分です。ここでは通常、外から来た値を「値」として扱う仕組み（プレースホルダ）が働き、命令文として解釈されることはありません。しかし捏造された項目には、「この中身は加工せずそのまま命令文に埋め込め」という指定が付けられていました。この指定が通ってしまったため、攻撃者が書いた問い合わせ文が丸ごとMetabaseの内部データベースに対して実行されます。利用者の情報を保持する表を直接書き換えれば、管理者としてログイン済みの状態を自分で作り出せる、という流れです。米国立標準技術研究所（NIST）はこれを、外から来た文字列がそのまま命令として扱われる典型例（CWE-89）に分類しています。

危険度が満点の10.0になったのは、認証も権限も利用者の操作も一切不要で、しかもMetabaseの管理範囲を越えて接続先のデータベースにまで被害が及ぶためです。攻撃の再現手順は8月10日ごろから出回っており、更新していない環境が見つかれば誰でも同じことができる状態にあります。

CVE-2026-59827：問い合わせ結果に紛れ込んだ「仕込み」を鵜呑みにする

6月末に公表された危険度9.9の欠陥です。Metabaseでは、利用者がSQLというデータベース向けの問い合わせ言語を直接書いて実行できます。同梱の「H2」という簡易データベースに対してこの生のSQLを実行すると、返ってくる結果の中に「OTHER（その他）」という種類の列が混ざることがあります。問題は、Metabaseがこの列の中身を検証せずにそのままJavaのプログラム部品として復元（デシリアライズ）してしまう点にありました。デシリアライズとは、保存や通信のために文字列化されたデータを、元のプログラム上の部品に戻す処理のことです。

攻撃者はこの仕組みを逆手に取り、復元されると悪意ある命令が動き出すように細工した部品を、問い合わせ結果に忍ばせます。Metabaseがそれを疑わずに組み立て直した瞬間、サーバー上で攻撃者の命令が実行されます。NISTはこれを「信頼できないデータのデシリアライズ」（CWE-502）として分類しています。悪用に管理者権限は不要で、SQLを実行できる一般利用者のアカウントがあれば足ります。初期状態のH2サンプルデータベースがそのまま経路になるため、標準構成のMetabaseの多くが該当します。

CVE-2026-50148：Snowflake接続を悪用してドライバを差し替える

7月に公表された、これも危険度10.0の欠陥です。舞台になるのは、Metabaseが外部のデータ保管サービス「Snowflake」（クラウド上に大量のデータをためて分析する、いわゆるデータ倉庫）へ接続する仕組みです。Metabaseは各種データベースにつなぐために「ドライバ」と呼ばれる接続用の部品を読み込んで使いますが、Snowflake用ドライバに、接続先のサーバーからMetabaseの動くマシンへ任意のファイルを書き込めてしまう欠陥がありました。

これを悪用すると、攻撃者はまず自分が用意した偽のSnowflakeサーバーを指す接続をMetabaseに設定します。Metabaseがそこへ接続した際、偽サーバーはMetabase自身のドライバ部品を悪意あるものにこっそり上書きします。次にMetabaseがそのドライバを読み込んだ瞬間、差し替えられた中身がプログラムとして動き出します。もとをたどれば、同梱されていたSnowflakeのJDBCドライバ（Javaからデータベースにつなぐための標準部品）が抱えていた欠陥で、外部の部品に依存することのリスクが表面化した「サプライチェーン型」の側面を持ちます。同種の構図はSnowflakeのコマンドツールの脆弱性でも指摘されており、自社が取り込んでいる部品を点検したい場合はオープンソース部品の安全性を確認する方法も参考になります。悪用にはデータベース接続を追加・変更できる権限（通常は管理者）が必要です。

CVE-2026-59826：危険な接続設定のチェックをすり抜ける

危険度9.1の欠陥で、Metabaseに新しいデータベースをつなぐ「接続登録」の画面が舞台です。H2データベースは接続設定の文字列の中に、初期化時に自動でSQLを実行させる指定などを書き込めます。この指定を悪用すればサーバー側で任意のプログラムを走らせられるため、本来Metabaseは危険な接続設定をはじく検査を行うべきでした。ところがその検査を一部の経路ですり抜けられる不備があり、管理者が細工したH2接続を登録すると、サーバー上で任意のJavaコードが実行されてしまいます。NISTはこれを「コード生成の不適切な制御」（CWE-94）として整理しています。

Metabaseはなぜ狙われ続けるのか

Metabaseにとって、乗っ取りの脆弱性は初めてではありません。2023年にはログイン前でも悪用できる致命的な穴（CVE-2023-38646／危険度9.8）が見つかり、CISAが攻撃確認リストに載せる事態になりました。この一件をきっかけに、Metabaseは新規インストールでH2を正式な接続先としてサポートしない方針へ舵を切っています。それでも2026年に入って3月・6月・7月・8月と、経路を変えながら重大な欠陥が続いています。

背景には、Metabaseという製品の立ち位置そのものがあります。あらゆる種類のデータベースにつなげることが売りなので、外部から取り込む接続部品の数がどうしても多くなる。誰でも使えることが売りなので、生のSQLを一般利用者に開放する設計になる。すぐ試せることが売りなので、初期状態で簡易データベースを同梱する。使いやすさのために選んだ設計が、そのまま攻撃されうる面の広さになっているという構図です。Dark Readingの報道も、Metabaseが「つながっている先の広さ」ゆえに1件の欠陥の影響範囲が跳ね上がる点を指摘しています。3年前のCVE-2023-38646が今なお数千台で未修正のまま残っているという調査もあり、今回も同じ道をたどる環境は少なくないと見られます。

これまでの経緯

← スワイプで移動

攻撃が始まったのが8月2日、Metabaseが気づいたのが3日、利用企業に伝わったのが6日です。気づかれずに動けた時間が3日以上あったことになります。この空白の期間に何が持ち出されたかを完全に把握するのは難しく、各社の公表文が「閲覧を確定できた件数」と「可能性を否定できない件数」を分けて書いているのはそのためです。

影響を受けるバージョンと安全な修正版

まずCVE-2026-72898についてです。対象は1.58系以降のすべてで、1.57系以前は影響を受けません。無料のオープンソース版はバージョンの先頭が「0」、企業向け版は「1」で始まりますが、続く番号は共通です（例：企業向け1.60.17はオープンソース版0.60.17にあたります）。下の表では系統を「x.60系」のように書きます。

クラウド版（Metabase Cloud）を使っている場合、更新は運営側ですでに適用済みです。ただし今回はそのクラウド基盤が攻撃を受けた側なので、更新が済んでいることと自社のデータが無事であることは別の話になります。Metabaseから個別通知が届いていないか、社内の管理者宛メールを確認してください。

自社サーバーやDockerで動かしている「セルフホスト」の場合は、自分たちで上の表の版へ上げる必要があります。JARファイルやDockerイメージを差し替えて再起動する形です。すぐに更新できない場合の応急処置として、開発元は /api/session/reset_password への通信をロードバランサやリバースプロキシで遮断する方法を挙げています。パスワード再設定が使えなくなる代わりに、攻撃の入口だけを塞げます。

なお6月・7月に公表された残り3件については、上の表の版へ上げれば同時に塞がります。単体での修正版は、CVE-2026-59827／59826がx.58.15.1・x.59.12・x.60.6.3・x.61.2以降、Snowflake経路のCVE-2026-50148がx.54.24・x.55.24・x.56.25・x.57.19・x.58.14・x.59.10・x.60.4以降です。x.57系以前を使い続けている場合でも、少なくともこれらの番号以降には上げてください。

侵入された形跡の見つけ方

更新して終わり、とはいかないのが今回の厄介なところです。公表前から攻撃が動いていたため、更新前にすでに入られていた可能性を自分で確かめる必要があります。開発元は、Webサーバーのアクセス記録で次の並びを探すよう案内しています。

この並びが見つかった場合、あるいは記録を残しておらず判断がつかない場合は、開発元が示す事後対応をひととおり実施することになります。すべてのログイン状態を無効化する（内部データベースの core_session テーブルの行を削除）、身に覚えのないAPIキーがないか確認して無効化する、管理者アカウントが勝手に増えていないか棚卸しする、Metabaseにつないでいた全データベースのパスワードを入れ替える、接続先データベース側の記録に不審な問い合わせがないか確認するの5つです。

Frameworkが通知を受けたその日のうちに認証情報を入れ替えたのは、4番目にあたります。攻撃者が持ち出したのが接続情報だった場合、Metabaseを直しても接続先には入り放題のままだからです。ここを飛ばすと、更新したのに数週間後に別経路で被害が出るという最悪の展開があり得ます。

確認できていること、まだ分からないこと

今すぐできる対策

やることは3段階です。まず自社にMetabaseがあるかを確かめる。分析基盤は情報システム部門を通さず現場が立てていることが多く、「うちは使っていないはず」が最も危ない前提になります。Dockerで動いている社内サーバー、検証用に立てたまま忘れられている環境、外部の開発会社が構築した集計画面。いずれも対象です。バージョンは、Metabaseの画面右上の歯車から管理者向けの設定画面を開けば確認できます。

次に上の表の版へ更新する。これが唯一の根本対策です。すぐに手が回らない場合は、パスワード再設定の窓口だけを遮断するか、Metabase自体をインターネットから見えない位置（社内ネットワークやVPNの内側）へ移してください。Wizの調査では、クラウド環境で見つかったセルフホストのMetabaseのうち約4分の1がインターネットから完全に到達可能な状態でした。ここを閉じるだけでも、無差別に走査してくる攻撃の対象からは外れます。

最後に入られていた前提で点検する。前述の記録の並びを探し、見つかれば認証情報の総入れ替えへ進みます。この工程を省いて更新だけで済ませると、接続先データベースへの通り道が残ったままになります。同じ順番の考え方は、開発支援ツールの乗っ取り脆弱性のように認証情報が奪われる型の事案では共通して有効です。

よくある質問

まとめ

今回のCVE-2026-72898は、社内の数字を眺めるために置いた画面が、そのまま会社の顧客名簿への近道になっていたという話です。パスワード再設定という誰でも触れる窓口に細工した文字列を1回送るだけで管理者になれてしまい、修正版が出るより先に、Framework・Tally・n8n・Kilo Code・Checklyの5社から顧客データが持ち出されました。危険度10.0という数字は計算上そう出たというだけでなく、実際に起きた被害の広さとも一致しています。

やるべきことははっきりしています。自社にMetabaseがあるかを確かめ、x.58.24／x.59.21／x.60.17／x.61.11／x.62.9／x.63.5のうち該当する版へ上げ、記録を見て入られた形跡がないかを確認する。この3つです。6月・7月に公表された3件も、同じ更新でまとめて塞がります。あわせて、本番データベースと同じ厳しさで分析基盤を守れているか、社内のどこに「見るためだけの写し」が置かれているかを、この機会に棚卸ししておくとよいでしょう。続報や国内での影響が確認され次第、本記事を更新します。

参照元

• ▸ Metabase Security Advisory - SQL injection using an unauthenticated endpoint leading to admin access（GHSA-vwf4-m7j8-wcjf / CVE-2026-72898）
• ▸ Metabase - Security update（公式発表）
• ▸ NVD - CVE-2026-72898
• ▸ CISA - Known Exploited Vulnerabilities Catalog
• ▸ Wiz - Inside the Metabase SQLi: Exploited in the Wild
• ▸ TechCrunch - Computer maker Framework notifies 'all customers' of a data breach
• ▸ n8n - Metabase security incident update
• ▸ Anaconda - Metabase Incident Impacting Kilo Code Data
• ▸ BleepingComputer - Metabase SQLi zero-day exploited in customer data-theft attacks
• ▸ SecurityWeek - Metabase Patches Vulnerability Exploited as Zero-Day
• ▸ Dark Reading - Metabase SQL Zero-Day Attacks Could Have Wide Blast Radius
• ▸ Metabase Security Advisory - Unsafe Deserialization of H2 Query Results（CVE-2026-59827）
• ▸ Metabase Security Advisory - Arbitrary Code Execution via Database Connection Detail Bypass（CVE-2026-59826）
• ▸ Metabase Security Advisory - Arbitrary File Write via Malicious Snowflake Connection（CVE-2026-50148）
• ▸ NVD - CVE-2023-38646（2023年のH2関連の乗っ取り脆弱性）