--- title: "LEAN BODYの不正アクセスと約44万件の取得｜Metabaseの脆弱性とBIツールの公開設定・パッチ適用" url: "https://www.issoh.co.jp/tech/details/18168/" published: 2026-10-08 updated: 2026-10-08 categories: ["セキュリティ"] publisher: "株式会社一創" --- # LEAN BODYの不正アクセスと約44万件の取得｜Metabaseの脆弱性とBIツールの公開設定・パッチ適用 オンラインフィットネスサービスLEAN BODYを運営する株式会社LEAN BODYは2026年9月15日、社内のデータ分析に使っていたツール「Metabase」の脆弱性を突かれ、データベースから顧客情報を取得されたと公表しました。対象は退会者を含む約44万アカウントです。本記事では公式発表に沿って経緯を整理し、取得された情報を重さで仕分けたうえで、利用者が今日回す点検手順をまとめます。後半では、Metabaseなどのセルフホスト型BIツールを運用する企業向けに、版の確認、更新までの遮断、侵害の痕跡探し、DB権限の絞り込みを実行できるコードで示します。 ## まとめ：LEAN BODYの不正アクセスで確定した事実と利用者・BI運用者が今やること 確定しているのは、2026年8月11日に最初の不正アクセスがあり、8月31日、9月7日、9月9日の三回にわたってデータベースから顧客情報が取得されたこと、9月8日に異常を検知し、9月9日に経路の遮断とツールの修正版への更新を済ませたことです。同社は脆弱性情報を定期的に確認して更新する運用ができていなかったことも要因になった可能性が高いと認めています。一方、脆弱性の種類やCVE番号、使っていたMetabaseの版は公表されていません。 利用者の打ち手は、同じパスワードを使っている他サービスの変更、LEAN BODYのパスワード変更、同社を装う不審なメールへの警戒の三つです。Metabaseを社内で使っている企業は、稼働中の版が修正版以上かをすぐに確かめてください。2026年8月にはCISAが悪用を確認したMetabaseの脆弱性が公開されており、更新の遅れがそのまま侵入口になる状況です。 | 項目 | 公表されている内容 | | --------- | --------------- | | 最初の不正アクセス | 2026年8月11日 | | 情報の取得 | 8月31日・9月7日・9月9日 | | 検知・遮断 | 9月8日検知・9月9日遮断 | | 侵入の起点 | 分析ツールMetabase | | 対象件数 | 約44万アカウント | | カード番号 | 下4桁のみ（全体は非保有） | | 脆弱性の種類 | 非公表 | ## 公表内容を時系列で確認する｜8月11日の侵入から9月9日の遮断までの約一か月 ### 最初の侵入から異常の検知までに約四週間かかったことが示す監視の空白 LEAN BODYの[公式発表（2026年9月15日）](https://lean-body.co.jp/news/JlBWMCs7)によると、同社環境への最初の不正アクセスは8月11日でした。その後、8月31日と9月7日に不正アクセス者がデータベースから顧客情報を取得し、同社が異常を検知したのは9月8日です。最初の侵入から検知まで28日が経っています。 この間に二回の取得が済んでいた点が、本件で最も重い事実です。分析ツールは社員が日常的にクエリを投げる場所なので、大量の読み出しがあっても業務の範囲に紛れやすくなります。分析ツールへのログインやエクスポートを監視の対象から外していると、侵入に気付く手掛かりがなくなります。 ### 9月9日の遮断と修正版への更新から個人情報保護委員会への速報まで 調査を始めた翌日の9月9日にも顧客情報が再び取得されましたが、同日中に不正アクセスの経路を遮断し、Metabaseを修正版へ更新しています。9月11日には個人情報保護委員会へ速報を提出し、9月15日に公表と対象者へのメール送付を始めました。確報は詳細な調査結果がまとまった段階で委員会へ出す予定とされています。 実施済みの対策として挙げられたのは、修正版への更新、接続経路の外部遮断、全セッションの失効、不正に作成されたアカウントとアクセスキーの無効化、接続情報の再発行、ログ保存期間の延長、DBへのアクセス権限の最小化、脆弱性情報の毎日の確認です。今後はMetabaseの利用を終了し、より安全な環境へ移る方針です。 ### 公表文が認めた要因とCVE番号や稼働中の版が書かれていない点の扱い 公表文は、Metabaseにセキュリティ上の脆弱性があったこと、そして脆弱性情報を定期的に確認して必要な更新を実施できなかったことが要因になった可能性が高いことを認めています。原因を外部の未知の攻撃ではなく、自社の更新運用に求めた書き方です。 ただし、どの脆弱性が悪用されたのか、稼働していた版が何だったのかは書かれていません。本記事では後半で時期の重なるMetabaseの脆弱性を取り上げますが、LEAN BODYの事案と同一であるとは断定しません。点検の手順は、どの脆弱性であっても共通して使えるものに絞って示します。 ## 取得された情報を種類別に仕分ける｜身体情報・認証情報・法人利用者の氏名 ### 体重や生年月日など健康管理サービス特有の入力情報が持つ重さと悪用 取得の対象は、メールアドレス、ニックネーム、性別、生年月日、都道府県、身長、体重、目標体重、活動量、運動の頻度や目的、登録日時や利用状況の記録などです。項目は利用者ごとに異なり、登録していない項目は対象になりません。 メールアドレスと生年月日、体重や運動の目的がひとまとまりで出ている点が、この事案の特徴です。ダイエットや健康を話題にした詐欺メールは、本人の入力内容に沿った文面で送れるため信じられやすくなります。パスワードは変えられますが、生年月日や身体の記録は取り消せません。 ### 暗号化されたパスワードと復号に要る情報が取得されていない場合の危険度 パスワードは暗号化された状態で取得されました。同社は、解読には別途厳重に管理している情報が必要で、その情報は今回取得されていないため、元のパスワードが判明する可能性は低いと説明しています。 それでも同社は念のためパスワードの変更を求めています。鍵が無事でも、変更しておけば将来の調査で新しい事実が出ても影響を受けません。同じパスワードを他のサービスで使っている場合は、そちらの変更を先に済ませるのが安全です。 ### 福利厚生経由の法人利用者は氏名・所属法人・従業員番号まで対象になる 一般の会員について同社が預かっているのはニックネームだけで、氏名は登録項目にありません。ただし、法人の福利厚生制度を通じて使っている一部の利用者は、氏名、所属法人名、従業員番号も対象です。ニックネームに本名を設定していた場合も同様です。 福利厚生でLEAN BODYを導入していた企業は、従業員の氏名と従業員番号が自社の外で取得されたことになります。社員を名乗る不審な連絡や、社内の人事・総務を装うメールへの注意喚起を社内に出しておくと、二次被害を抑えられます。 | 取得された項目 | 想定される悪用 | 取り消し | | --------- | ----------- | ----- | | メールアドレス | なりすましメールの宛先 | 不可 | | 生年月日・身体情報 | 文面を合わせた詐欺 | 不可 | | 暗号化パスワード | 鍵が漏れた場合の解読 | 変更で可能 | | カード番号下4桁 | 本人確認を装う連絡 | 不可 | | 氏名・従業員番号 | 社内を装う標的型メール | 不可 | ## 利用者が今日やる点検手順｜パスワードの変更と不審なメールの見分け方 ### LEAN BODYと同じパスワードを使う他サービスを先に変更しておく理由 同社は、LEAN BODYのパスワードを設定ページから変更するよう案内しています。サービスは通常どおり使えるため、変更はすぐに行えます。あわせて、同じか似たパスワードを使っている他サービスも変更してください。 順番は、パスワード再設定の受け口になるメールアカウント、決済や送金に関わるサービス、SNSの順で組みます。変更と同時に二要素認証を有効にしておくと、パスワードが知られても単独では入れなくなります。 ### 本件に便乗した不審なメールやSMSを送信元のアドレスで見分ける手順 同社からの本件の連絡は noreply@lean-body.jp から、問い合わせへの返信は support@lean-body.jp から送られます。これ以外のアドレスから届いたもの、パスワードや支払い情報の入力を求めるものは同社からの連絡ではありません。同社はメールや電話でパスワードや支払い情報を尋ねることはないと明言しています。 送信元の表示名は簡単に偽装できるため、表示名ではなくメールアドレスそのものを確かめます。迷ったらメール内のリンクは開かず、[LEAN BODYのよくある質問ページ](https://support.lean-body.jp/hc/ja/articles/5647772459806)をブックマークや検索から直接開いて確認してください。 ## Metabase脆弱性CVE-2026-72898の時系列｜公開日・KEV追加日・侵入日 ### 未認証のSQLインジェクションで管理者権限と接続先DBの認証情報が取られる 2026年8月6日、Metabaseは[セキュリティアドバイザリGHSA-vwf4-m7j8-wcjf](https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf)でCVE-2026-72898を公開しました。認証の要らないエンドポイント経由で任意のSQLをMetabaseのアプリケーションDBへ注入でき、インスタンスの管理者権限を奪えるというもので、CVSSは10.0です。管理者になった攻撃者は設定を変え、接続先DBの認証情報を盗み、その接続で読めるデータを書き出せます。 影響を受けるのは58系から63系で、修正版は x.58.24、x.59.21、x.60.17、x.61.11、x.62.9、x.63.5 です。先頭の0はオープンソース版、1はEnterprise版を表します。仕組みとしてのSQLインジェクションは[SQLインジェクションとは](https://www.issoh.co.jp/column/details/3030/)、CVSSやCWEの読み方は[CVEとCWEの違いとは](https://www.issoh.co.jp/tech/details/5119/)で整理しています。 ### アドバイザリ公開の8月6日と最初の侵入の8月11日が示すパッチ適用の猶予 [Metabaseの公式ブログ](https://www.metabase.com/blog/security-update-6-aug-2026)によると、この脆弱性は当初、Metabase Cloudへの攻撃で未知の脆弱性として使われていました。Cloudの利用者は更新済みで、対応が要るのはセルフホストの利用者です。[CISAのKnown Exploited Vulnerabilitiesカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)には2026年8月11日に追加されています。 LEAN BODYへの最初の不正アクセスも8月11日でした。同社はCVE番号を公表していないため同一とは言えませんが、もしこの脆弱性であれば、修正版の公開から5日で侵入されたことになります。悪用が確認された脆弱性では、月次のパッチ適用では間に合わないという見積もりで運用を組む必要があります。 ## 自社のMetabaseを点検する手順｜版の確認・更新・侵害の痕跡探し ### 稼働中のMetabaseの版をpropertiesから取得して修正版と比べるスクリプト Metabaseは /api/session/properties でインスタンスの設定値を返し、その中の version.tag に稼働中の版が入ります。次のスクリプトは版を取得し、アドバイザリの修正表と比べて更新が要るかを判定します。`jq` が必要です。 ``` #!/usr/bin/env bash # 使い方: ./check_metabase.sh https://metabase.example.com set -eu BASE="$1" TAG=$(curl -s "$BASE/api/session/properties" | jq -r '.version.tag') echo "version: $TAG" IFS=. read -r EDITION MAJOR PATCH _ <<< "${TAG#v}" case "$MAJOR" in 58) FIX=24 ;; 59) FIX=21 ;; 60) FIX=17 ;; 61) FIX=11 ;; 62) FIX=9 ;; 63) FIX=5 ;; *) echo "58〜63系以外：本アドバイザリの修正表に載らない系。最新系への更新状況を個別に確認"; exit 0 ;; esac if [ "$PATCH" -lt "$FIX" ]; then echo "要更新：$EDITION.$MAJOR.$FIX 以上へ上げる"; exit 1 else echo "修正版以上（$EDITION.$MAJOR.$FIX 以上）" fi ``` 応答を差し替えて判定部分を動かすと、v0.61.9 は「要更新」で終了コード1、v1.61.11 と v1.58.24.1 は「修正版以上」、v0.57.3 は対象外として扱われます。終了コードを見て監視やCIに組み込めます。57系以前は本アドバイザリの対象外ですが、古い系を使い続けること自体が更新運用の遅れを示すので、別途最新系への移行を計画してください。更新手順は[Upgrading Metabase](https://www.metabase.com/docs/latest/installation-and-operation/upgrading-metabase)にあり、作業前にアプリケーションDBのバックアップを取ることが求められています。 ### 更新までのつなぎとしてreset\_passwordへの到達を止めるnginxの設定例 すぐに更新できない場合、アドバイザリは /api/session/reset\_password エンドポイントを遮断する回避策を示しています。Metabaseの前段にnginxを置いているなら、次の設定で外部からの到達を止められます。 ``` location = /api/session/reset_password { return 403; } ``` この設定を入れるとパスワード再設定の機能も使えなくなります。あくまで更新までのつなぎで、修正版へ上げたら外して構いません。 ### ログ抽出条件｜reset\_passwordの400と直後のuser/current成功 Metabaseの公式ブログは、侵害の痕跡として POST /api/session/reset\_password が400で返った後に GET /api/user/current が200で返る組み合わせを挙げています。nginxの標準的なcombined形式のアクセスログなら、次の手順で該当する接続元を抽出できます。 ``` LOG=/var/log/nginx/access.log # reset_password が 400 で返った接続元IPを集める grep -E '"POST /api/session/reset_password[^"]*" 400 ' "$LOG" | awk '{print $1}' | sort -u > suspect_ips.txt # 同じ接続元が user/current を 200 で取得した行を表示する awk 'NR==FNR{ip[$1];next} ($1 in ip) && /"GET \/api\/user\/current[^"]*" 200 /' suspect_ips.txt "$LOG" ``` IPアドレスを文字列の部分一致ではなく完全一致で照合しているため、203.0.113.7 を調べるときに 203.0.113.70 を拾うことはありません。ヒットした接続元があれば、その時刻以降の操作を侵害の前提で調べます。ログの見方全般は[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)が使えます。 ### 更新後にセッション失効・APIキー確認・接続DBの認証情報を入れ替える順番 修正版へ上げただけでは、すでに奪われたセッションや作られたAPIキーは残ります。アドバイザリは更新後の作業として、アプリケーションDBの core\_session テーブルの全行削除によるセッション失効、APIキーの確認と不明なキーの削除、管理者アカウントの変更有無の確認、接続先DBの認証情報の入れ替え、データウェアハウス側のログ確認、Metabaseの操作履歴とクエリ履歴の確認を挙げています。 ``` -- Metabaseのアプリケーションデータベースで実行する（全ユーザーが再ログインになる） DELETE FROM core_session; ``` LEAN BODYが実施済みとした対策も、全セッションの失効、不正に作られたアカウントとアクセスキーの無効化、接続情報の再発行と、この順番にほぼ沿っています。接続先DBのパスワードを替えずに済ませると、盗まれた認証情報で直接DBへ入られる経路が残ります。 ## BIツールの公開設定と権限を見直す｜外部遮断・読み取り専用・列単位の付与 ### 社内向けのBIツールをインターネットから直接到達させない構成の判断 LEAN BODYが対策に挙げた「接続経路を外部から遮断」は、BIツール運用の基本です。社内の分析にしか使わないのであれば、インターネットから直接ログイン画面に届く必要はありません。[nginxのaccessモジュール](https://nginx.org/en/docs/http/ngx%5Fhttp%5Faccess%5Fmodule.html)を使うと、社内やVPNの出口アドレスだけを通す設定にできます。 ``` location / { allow 203.0.113.0/24; # 社内・VPNの出口アドレス deny all; proxy_pass http://127.0.0.1:3000; } ``` 注意したいのは公開共有機能です。[MetabaseのPublic sharing](https://www.metabase.com/docs/latest/embedding/public-links)は既定で有効になっており、ダッシュボードを社外へ公開リンクで出している場合、上の制限で見られなくなります。管理画面のSettingsにあるPublic sharingで有効なリンクの一覧を確かめ、本当に公開が要るものだけを別の経路に切り出してください。 ### 接続DBユーザーを読み取り専用にしてパスワード列を見せない列単位GRANT [Metabaseのドキュメント](https://www.metabase.com/docs/latest/databases/users-roles-privileges)は、接続には専用の読み取り専用ユーザーを使い、CONNECTとSELECTだけを与える構成を勧めています。さらに一歩進めて、分析に要らない列は見せない設定にしておくと、BIツールが乗っ取られた場合にも読み取れるデータの範囲を限定できる仕組みです。PostgreSQLでは[GRANT](https://www.postgresql.org/docs/current/sql-grant.html)で列単位のSELECTを付与できます。 ``` -- 分析用ロール（ログイン不可）にまとめて権限を持たせる CREATE ROLE analytics NOLOGIN; GRANT CONNECT ON DATABASE app TO analytics; GRANT USAGE ON SCHEMA public TO analytics; -- users表はパスワード・メールアドレス列を除いて付与する GRANT SELECT (id, gender, birth_year, prefecture, created_at) ON public.users TO analytics; GRANT SELECT ON public.workout_logs TO analytics; -- Metabaseが接続するユーザーにロールを渡す CREATE USER metabase WITH PASSWORD 'ここに十分長いパスワード'; GRANT analytics TO metabase; ``` LEAN BODYでは暗号化されたパスワードと契約・支払いの記録まで取得されています。分析にパスワードの列は要りません。運用DBへ直接つながず、個人を特定する列を除いた分析用の複製や集計テーブルにつなぐ構成にすれば、さらに被害の天井が下がります。 ### BIツールを使い続けるか撤去するかを決める条件と見送ってよい場面 LEAN BODYはMetabaseの利用を終えると決めました。自社で判断するときの条件ははっきりしています。セルフホストのBIツールを使い続けてよいのは、脆弱性情報を毎日確認して数日以内に更新できる担当者がいて、インターネットから直接届かない構成になっている場合です。どちらかが欠けるなら、更新を提供元が引き受けるクラウド版へ移すか、使用頻度の低い環境は撤去するほうが安全です。 逆に、社内の閉じたネットワークだけで動き、接続先が個人情報を含まない集計テーブルに限られているなら、移行の工数をかけるより更新の仕組みを先に整えるほうが合理的です。Metabaseの構成やエディションの違いは[Metabaseとは](https://www.issoh.co.jp/tech/details/16142/)、導入と共有の操作は[Metabaseの使い方](https://www.issoh.co.jp/tech/details/7996/)で解説しています。 ## 漏えい等報告と脆弱性監視の体制｜利用企業と運用者それぞれの段取り ### 個人情報保護委員会への報告対象となる四つの類型と速報・確報の期限 [個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、報告の対象は要配慮個人情報の漏えい等、財産的被害のおそれがある個人データ、不正の目的をもって行われたおそれがある行為による漏えい等、本人の数が1,000人を超える漏えい等（民間事業者）の四類型です。期限は、速報が発覚日から3〜5日以内、確報が30日以内、不正目的の場合は60日以内とされています。 LEAN BODYは9月8日の検知から3日後の9月11日に速報を出しています。自社が分析基盤経由の侵害を受けた場合も、外部の攻撃による取得であれば不正目的の類型に入り得るため、件数にかかわらず報告の要否を検討してください。期限の数え方と書式は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で詳しく扱っています。 ### OSSの脆弱性情報を毎日確認する体制を小さく始めるための手順と外部委託 LEAN BODYが新たに始めたのは、脆弱性情報を毎日確認して速やかに対応する運用です。小さく始めるなら、まず社内で動いているOSSとその版の一覧を作り、GitHubのSecurity Advisoriesやベンダーのブログを購読し、CISAのKEVに載った脆弱性は即日の対応対象にするという三段で組めます。上で示した版判定スクリプトを毎日回すだけでも、更新漏れには気付けます。 同じく事業者側の保管データが外へ出た事例として、[タイムズカーの不正アクセス](https://www.issoh.co.jp/tech/details/17925/)や[Gyazoの不正アクセス](https://www.issoh.co.jp/tech/details/17839/)も比較の材料になります。同じ8月にBIツールの既知の脆弱性を突かれ、修正の適用が間に合わなかったと公表した事例は[VOISINGの不正アクセスとパッチ適用の期限設計](https://www.issoh.co.jp/tech/details/18174/)で、深刻度別の適用期限とあわせて整理しています。攻撃を受けずにシステムの設定不備で学生の氏名が通信データに載った事例としては、[OfferBoxの情報漏洩](https://www.issoh.co.jp/tech/details/18170/)があります。外部からの入口を一度洗い出すなら[脆弱性診断](https://www.issoh.co.jp/column/details/13101/)の種類と費用の考え方が、点検方法を選ぶ際の判断材料です。社内BIや管理画面の公開範囲、DB権限の設計を含めて第三者に確かめてもらいたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で入口からDBまでの経路をまとめて点検できます。 ## よくある質問 LEAN BODYの不正アクセスとMetabaseの脆弱性について、利用者と運用者から出やすい質問をまとめました。 ### LEAN BODYはこのまま使い続けても大丈夫ですか？ 同社は、会員情報の改ざん、アカウントの不正利用、不正な請求、サービス提供への影響は現時点で確認されていないとし、サービスは通常どおり使えると説明しています。不正アクセスの経路は9月9日に遮断済みです。続けて使う場合も、パスワードの変更と、同社を装う不審なメールへの警戒は済ませておいてください。 ### 退会済みでも対象に含まれますか？ 含まれます。対象の約44万件は退会者を含むアカウント数で、過去に利用していた人や、法人・健康保険組合などを通じて利用していた人も対象です。対象者には9月15日から順次メールが送られていますが、届いていなくても対象の可能性があると同社は案内しています。 ### クレジットカードの利用停止は必要ですか？ 取得されたのはカード番号の下4桁と決済サービス上の識別番号、請求や返金の記録です。カード番号全体とセキュリティコードは外部の決済代行サービスが預かっており、同社のデータベースには保存されていません。直ちに停止する必要は低いものの、下4桁を示して本人確認を装う連絡には応じないでください。 ### LEAN BODYで悪用されたのはCVE-2026-72898ですか？ 公表されていません。同社が明らかにしていない情報は、脆弱性の種類、CVE番号、使っていた版です。CVE-2026-72898は2026年8月6日に公開され、8月11日にCISAのKEVへ追加された脆弱性で、最初の侵入日と時期が重なりますが、同一であるとは断定できません。続報で明らかになれば本記事を更新します。 ### 自社のMetabaseは何から点検すればよいですか？ 最初に稼働中の版を確かめ、修正版より古ければすぐに更新します。更新できない間は /api/session/reset\_password への到達を止めます。更新後はセッションの失効、APIキーと管理者アカウントの確認、接続先DBの認証情報の入れ替え、アクセスログの痕跡確認の順で進め、最後にインターネットからの到達範囲とDB権限を見直してください。 ## 関連記事 - [Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】](https://www.issoh.co.jp/tech/details/16142/)：セルフホストとクラウド版を選び直すときの前提に - [Metabaseの使い方｜起動からダッシュボード共有まで・料金と商用利用【v0.63対応】](https://www.issoh.co.jp/tech/details/7996/)：公開共有と接続設定の操作を確かめるときに - [タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計](https://www.issoh.co.jp/tech/details/17925/)：退会者のデータまで対象になった同系統の事例 - [Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し](https://www.issoh.co.jp/tech/details/17839/)：受付サーバー起点でDBまで届いた事例との比較に - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：侵害を受けた側の報告期限と書式 - [SQLインジェクションとは？仕組み・攻撃例・対策をコード付きで解説](https://www.issoh.co.jp/column/details/3030/)：今回の脆弱性種別の仕組みを押さえる --- 出典: [LEAN BODYの不正アクセスと約44万件の取得｜Metabaseの脆弱性とBIツールの公開設定・パッチ適用]()（株式会社一創）