Framework、全顧客の個人情報が流出。外部起因の漏洩は2年半で3度目

Metabaseのゼロデイ脆弱性を突いた攻撃で、氏名・住所・電話番号・メールアドレスが外部に出た。決済情報は無事だが、問われているのは事後対応の速さではない。

何が起きたか

分析ツールの穴から、顧客名簿がまるごと抜かれた。

Frameworkが利用するBI（ビジネスインテリジェンス）プラットフォーム「Metabase」のクラウドサービスが、現地時間8月3日に攻撃を受けた。パスワードリセット用のAPIエンドポイントに存在した未知のSQLインジェクション脆弱性が突かれ、認証なしでデータベースへの管理者アクセスが可能になった。

GitHubのセキュリティアドバイザリによる深刻度はCVSS 10.0、最高値だ。CVE番号は現時点で未割当。影響範囲はバージョン1.58以上のすべてのMetabaseインスタンスに及ぶ。

Metabaseは攻撃を検知した後、該当エンドポイントを遮断し、脆弱性を特定・修正。法執行機関に通報し、外部のフォレンジック企業に調査を依頼した。クラウド版は自動的にパッチが適用済みだが、セルフホスト版は手動でのアップデートが必要になる。

MetabaseがFrameworkに通知したのは8月6日。攻撃の発見から3日後だ。

6時間の対応、しかし

Frameworkの動きは速かった。

Metabaseからの通知を受けた後、ログを確認し、自社のMetabaseインスタンスが攻撃者にアクセスされたことを確認。通知から約6時間で全顧客にメールを送信した。

大企業でも数週間から数か月かかるのが常であることを考えれば、異例の速さだ。

流出したのは、氏名、メールアドレス、ログインIP、請求先・配送先住所、電話番号、会社名。法人顧客はこれに加えてVAT番号やEIN（雇用者識別番号）、請求先メールアドレスも含まれる可能性がある。

注文内容や決済情報はStripeで処理されており、今回の漏洩には含まれていない。

Frameworkの広報担当エリック・シューマッハー（Eric Schumacher）氏は、影響が「全顧客」に及ぶことを認めた。具体的な人数は明かしていない。

Metabaseに接続されたデータベースの認証情報はローテーション済み。Metabase以外のシステムへの不正アクセスや、管理者権限の変更は確認されていないという。

「limited」という言葉

Frameworkが顧客に送ったメールの件名は「Notice of Limited Data Breach（限定的なデータ漏洩のお知らせ）」だった。

氏名、住所、電話番号、メールアドレス、ログインIP。これだけの個人情報が揃えば、標的型フィッシングの材料には十分だ。コミュニティフォーラムでは、「basically all the personally identifiable information is there（個人を特定できる情報はほぼ全部入っている）」のに「limited」と呼ぶのは不誠実だ、という指摘が上がっている。

メールの末尾にはこうある。「多くの地域の規制は、氏名・メールアドレス・電話番号・住所の漏洩に対して通知を義務付けていません。それでも、お知らせしています」。

透明性への評価と、表現の選び方への違和感。コミュニティの反応はこの2つに割れた。

なぜBIツールに住所が必要だったのか

技術的に見て、Metabaseのゼロデイ脆弱性自体はFrameworkの責任ではない。だが、攻撃者がたどり着いた先に顧客のフルネームや住所、電話番号があったことは、Frameworkのデータ管理の設計に起因する。

BIツールの主な用途は、売上傾向の分析やユーザー行動の可視化だ。その目的に、個々の顧客の住所や電話番号は必要ない。匿名化された識別子（不透明キー）で十分だという声は、Redditのスレッドでもフォーラムでも繰り返し上がっている。

あるフォーラムユーザーは、GDPRの観点からFrameworkの対応を分析した。データの匿名化をしていないこと、BIプラットフォームに電話番号や正確な住所を送る必要がないこと、プライバシーポリシーが2020年から実質的に更新されていないこと、Metabaseへのデータ転送が目的外利用に当たりうること。4点を挙げ、いずれもデータ最小化の原則に反すると指摘している。

Framework自身も、今後の対策として「BIプラットフォームに共有するデータの幅と深さを見直し、分析に必要なカラムだけにアクセスを絞る」と述べた。裏を返せば、これまで絞っていなかったことを認めている。

2年半で3度目

今回の件を単発の不運として片付けるのは難しい。Frameworkが外部パートナーの侵害を通じて顧客の個人情報を流出させたのは、これが3度目だ。

2024年1月には、外部の会計パートナーであるキーティング・コンサルティング（Keating Consulting）の従業員がフィッシング攻撃に遭い、CEOを装ったメールに応じて顧客情報を含むスプレッドシートを渡してしまった。氏名、メールアドレス、未払い残高が流出した。

2025年6月には、欧州の修理パートナーであるLMR GermanyのWebインフラの脆弱性により、修理や返品に関連する一部顧客のPII（個人識別情報）が外部から閲覧可能な状態にあったことが判明した。

会計パートナー、修理パートナー、分析プラットフォーム。経路は毎回違うが、構造は同じだ。Frameworkの顧客データが、Frameworkではない場所で漏れている。

小規模なハードウェアスタートアップが業務のあらゆる側面を内製するのは現実的ではない。問題は外部パートナーへの依存そのものより、預けるデータの範囲と、パートナーのセキュリティ基準の検証が追いついていないことにある。

Frameworkだけの話ではない

Metabaseのゼロデイ被害はFrameworkに限らない。オンラインフォームビルダーのTallyも、同じ8月3日にMetabaseの分析環境が侵害され、メールアドレスとパスワードハッシュが流出したことを顧客に通知している。

Metabaseはオープンソースで、GitHubのスター数は4万8000を超える。公式サイトによれば10万社以上が利用している。今回の脆弱性がバージョン1.58以降のすべてに影響するため、セルフホスト版を含めた被害の全容はまだ見えていない。

Metabase自身も「調査は予備的な段階」としている。

3年前の2023年7月にも、Metabaseには認証不要のリモートコード実行脆弱性（CVE-2023-38646、CVSS 9.8）が見つかっている。当時は悪用の証拠は確認されなかったが、2026年3月時点でも1万7000以上のMetabaseインスタンスがインターネットに公開された状態にあり、その多くが脆弱なバージョンのまま放置されていたという調査結果がある。

BIツールやCRM、分析プラットフォームといったサービスは、顧客のメタデータへのアクセスを前提に設計されている。あるフォーラムユーザーは「自分が勤める小規模テック企業では、30〜40の外部サービスにPIIを送っている。合法だし、業界では普通のことだ」と書いた。データ保護の理想と、事業運営の現実が衝突する場所に、今回の漏洩はある。

ノートPCの修理権とデータの修理権

Frameworkは、ハードウェアの透明性と修理の自由を掲げて支持を集めてきた。バッテリーもディスプレイもタッチパッドも、接着剤なしで交換できる。部品はネジ止め。修理ガイドは公開されている。「所有するとはどういうことか」を製品で示してきた企業だ。

だからこそ、データの扱いで業界標準の慣行を踏襲していたことへの落胆が大きい。「ハードウェアレベルで顧客を尊重するなら、データレベルでも同じことをしてくれ」。フォーラムの声は、称賛と失望が混ざっている。

通知の速さは確かに異例だった。6時間という対応速度は、多くの企業が手本にすべきものだ。だがその速さが称えられるほど、「なぜそもそもBIツールにフルの個人情報を渡していたのか」という疑問が際立つ。

火事の消火は見事だった。でも、なぜそこに燃えやすいものを置いていたのか。

関連記事

• ロンドン警視庁、ストーカーに被害者の新住所を渡す。英当局が是正命令
• 韓国外交官1万人の情報流出か、10カ月間の侵入を検知できず
• OpenAIのモデルがHugging Faceを侵害した
• Zoom、認証不要のアカウント乗っ取り脆弱性を緊急修正
• FortiGate 7万5000台の認証情報が流出。日本も被害圏内
• OracleのPeopleSoftに深刻度9.8のゼロデイ。100超の組織が標的に
• Outlookが暗号化設定を無視してメールを平文で受信していた可能性
• NSAツール流出の犯人、10年経っても不明のまま
• 7-Elevenで18万人分の個人情報が流出、身代金拒否後に公開
• Ghost CMSの脆弱性、大規模攻撃の踏み台に