Metabaseに深刻度Criticalの修正 CVE番号なし、自社運用は64.3.4へ

CVE番号は0件なのに、深刻度は「Critical」。BIツールのMetabaseが10月28日（日本時間19時ごろ）にGitHubで公開した勧告「Metabase 64 security update」は、そんな少し変わった形をしています。

自社でMetabaseを動かしているなら、オープンソース版は0.64.3.4以降、ProとEnterpriseは1.64.3.4以降に上げてください。Metabase Cloudは、Metabaseの側で版を上げます。

番号が無くても、後回しにしにくい

勧告は、個々の脆弱性を1件ずつ並べていません。64系を「security hardening release」と呼び、APIとクエリの入力の検証を強めたこと、公開リンクや埋め込みが返す情報を減らしたこと、利用を止めたユーザーのセッションの扱いを改めたことなどを、まとめて挙げています。CVEの欄は「No known CVE」です。

それでも後回しにしにくいのは、この夏から、Metabaseが国内で狙われ続けているからです。Metabaseが8月6日に公表したCVE-2026-72898は、認証なしでアプリケーションDBにSQLを流し込み、管理者の権限を取れる脆弱性でした。JPCERT/CCも8月14日に注意喚起を出しました。10月23日に更新した国内の不正アクセスの注意喚起では、攻撃の手口としてこの脆弱性を挙げ、8月上旬から9月上旬に悪用に使われたIPアドレスを載せています。

NEXT STAGEが10月13日に公表した不正アクセスも、Metabaseの脆弱性のリスクが公表されていた中で、第三者が不正なアカウントでデータベースを検索できた事故でした。

ちなみに、CVE番号の無いCriticalの勧告は今回が初めてではありません。8月11日にも、クエリの検証や権限、ネットワークへの露出にまたがる修正を、番号を付けずにまとめて出しています。

64.3で直ったのは、権限の境目

変更履歴を読むと、64.3で直った不具合の多くは、ログインできる人が、見てはいけないデータに手を伸ばせる種類です。

たとえば、データのサンドボックスで行を絞られた利用者が、元になる質問を編集すると、自分にかかった絞り込みを外せてしまう不具合。「Do not include」にした列を、手で書いたMBQLのクエリで読めてしまう不具合もありました。ネイティブクエリの権限が無い利用者への応答に、組み立てたSQLが入っていた点や、拒否したリクエストのエラーに非公開の質問の定義が混じっていた点も、64.3で直っています。

64.1では、もっと重いものが直っていました。管理者ではないのにSettingsの権限がある利用者が、OIDCの設定を書き換え、管理者を含む誰にでもなりすましてログインできた不具合です。

外からの攻撃だけを心配していると、見落としやすい種類でしょう。NEXT STAGEの件でも、データベースを検索したのは不正なアカウントでした。社員や委託先、取引先に配ったアカウントが1つ乗っ取られれば、こうした穴を通って、見せていないデータまで届いてしまいます。

うちの会社のMetabaseは、版によって扱いが違う

勧告が対象に挙げたのは「64.0以上、64.3.4未満」だけです。一方、フランスのCERT-FRは10月28日の注意喚起で、「0.64.3.4より前の版」と範囲を区切らずに書きました。64系より前をどう扱うかは、勧告からは読み取れません。

手がかりになるのは変更履歴です。見比べると、64.3の修正の多くは、同じ番号で63系の63.20と63.21、58系の58.37にも入っていました。

急ぎたいのは63系です。11月1日でサポートが切れるので、今の修正を当てても、その次の修正は届きません。64系はLTSで、2027年12月1日まで修正が出ます。

委託先が運用しているMetabaseも、扱いは同じです。データ分析の部署が自分で立てたものが、情シスの台帳に載っていないこともあるでしょう。逆に、社内でも委託先でもMetabaseを使っていなければ、今回の勧告は関係ありません。

64系で増えた設定は、上げたあとに

64系では、版を上げたあとの設定に、情シスの手がいちばんかかります。鍵も2要素の必須化も、管理者が設定しない限り効きません。

まず、セッションの署名鍵と暗号化の鍵。環境変数のMB_SESSION_SECRET_KEYを入れると、アプリケーションDBに手が届いても、それだけでは使えるセッションを作れなくなります。8月の脆弱性がアプリケーションDBへのSQLインジェクションだったことを思えば、真っ先に入れたい設定です。もう一方のMB_ENCRYPTION_SECRET_KEYは、DBの接続情報や2要素認証の秘密の値を暗号化します。どちらもオープンソース版で使えます。

ただし、扱いには注意が要ります。Metabaseの手引きは、openssl rand -base64 32で2つの値を作り、シークレットの管理ツールに置いて、すべてのノードで同じ組を使うよう勧めています。暗号化の鍵をなくすと、暗号化した値は戻せません。セッションの鍵を変えれば、全員がログアウトします。

2要素認証は、必須にできるようになりました。ProとEnterpriseでは、パスワードかLDAPでログインする全員に、2要素を求められます。設定は管理画面のSettings、Authentication、Overviewにある「Two-factor authentication」のカード。猶予期間を付けられ、期間が過ぎると、2要素を通っていないセッションは切れます。

Metabaseから外へつなぐ先も、絞れるようになりました。対象はデータベース、Webhook、地図のタイル、AIの提供元、OIDCの5つです。MB_WAREHOUSE_ALLOWED_NETWORKSなどの環境変数で、それぞれ「external-only」「allow-private」「allow-all」から選びます。社内のネットワークにあるDBにつないでいるなら、データベースの変数はallow-privateにすることになるでしょう。64.1では、Druidのドライバーを通じたSSRFも直っています。

版を上げると、動きが変わる所もあります。文書化されていないAPIの使い方は受け付けなくなり、質問の元になるモデルや質問すべてに、閲覧の権限が要るようになりました。自作の連携スクリプトや、ほかの部署が作ったダッシュボードが、急にエラーを出すかもしれません。

更新から設定までの手順

1. 社内と委託先で動いているMetabaseを洗い出し、版を確かめます。Dockerなら、イメージのタグ（metabase/metabase:v0.64.3.xの形）で分かります。
2. アプリケーションDBのバックアップを取ってから、64.3.4以降に上げます。63系以前から上げるなら、先に検証環境で、連携スクリプトと主なダッシュボードが動くかを見ておきます。
3. 管理画面の「Public sharing」で公開リンクの一覧を開き、要らないものを止めます。公開の共有は、初期の状態で有効です。8月に公表されたCVE-2026-72899は、公開した質問やダッシュボードのリンクを使い、認証なしでSQLを流し込める脆弱性でした。
4. 2つの鍵を入れ、ProとEnterpriseなら、猶予期間を付けて2要素の必須化を有効にします。期間が過ぎるとセッションが切れることは、先に社内へ知らせておきます。
5. インターネットから届く所に置いているなら、手前のリバースプロキシやファイアウォールで、つなげる相手を絞ります。Metabaseの手引きも、ポートをそのままインターネットに出さないよう注意を促しています。

64系からは、重大な脆弱性のある版で動かしていると、管理者の画面に消せない更新の案内が出るようになりました。とはいえ、番号の無い勧告は、CVEで突き合わせる脆弱性の管理では一覧に出てきません。Metabaseの手引きは、ProとEnterpriseにはSecurity Centerの通知を、オープンソース版には勧告と新しい版の告知を自分で追うことを勧めています。BIの担当と情シスのどちらがそこを見るのか、今のうちに決めておきたいところです。