ムラウチドットコムへの不正アクセス（Webシステムの脆弱性起点、顧客情報7,716,811件を外部へ持ち出し）
公表日
家電・パソコン通販のムラウチドットコムが不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。を受け、顧客の個人情報 7,716,811件が外部に持ち出されたことが確認されました。クレジットカード情報とログインのパスワードは含まれていません。
対象者は？
ムラウチドットコムの顧客です。持ち出されたのは氏名・住所・電話番号で、一部の方はメールアドレス・生年月日・性別も含まれます。クレジットカード番号などの決済情報と、ログインID・パスワードは別のシステムで管理されていたため対象外とされています。
対象の方には、2026年9月15日から会社が個別にメールを送っています。専用の問い合わせ窓口も設けられており、公式のお知らせで確認できます。
いますぐできること
- ムラウチを名乗るメール・SMS・電話で、カード情報やパスワードの入力、支払いを求められても応じない。注文の確認は公式サイトから自分で行う
- 住所や電話番号を知っている相手からの、身に覚えのない荷物や請求の連絡に注意する
何が起きたのか
2026年7月15日の未明、ムラウチドットコムの社内システムで障害が起きました。翌16日、復旧作業の途中で第三者による不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。の跡が見つかり、会社は外部からのアクセスを遮断して、専門の会社に調査を頼みました。7月24日の第一報では、情報が漏れた跡があることだけが伝えられました。9月15日の第二報で調査が終わり、7,716,811件の顧客情報が外部に持ち出されたことが確定しました。
なぜ起きたのか・なぜ広がったのか
報道によると、会社が管理するWebシステムの一部の弱点（脆弱性）が悪用され、そこを入り口に複数のシステムへ侵入されました。どのような弱点だったか、いつ侵入されたかは公表されていません。7月15日のシステム障害と攻撃の関係も公表されていません。
いまの状況2026-09-15 時点続報待ち
9月15日の時点で、情報が悪用された二次被害は確認されていません。本店の営業は続いています。問い合わせ窓口を一本にまとめるため公式SNSを一時休止しており、2026年11月ごろに再開する予定です。報道によると、再発防止策としてアクセス権限やパスワード管理の見直し、監視の強化、定期的な脆弱性診断を挙げています。
企業として考えたいこと
自社のWebサイトや通販システムの弱点を、最後に専門家に調べてもらったのはいつでしょうか。1つのシステムに入られたときに、他のシステムまで届かないようになっているかも確認したいところです。
技術的な要約
家電・PC通販のムラウチドットコムで、2026年7月15日未明に社内システム障害が発生し、翌16日の復旧作業中に第三者による不正アクセスの痕跡が見つかった。報道によれば、同社が管理するWebシステムの一部の脆弱性が悪用され、そこを起点に複数のシステムへ侵入された。7月24日の第一報では顧客情報漏えいの「痕跡」の確認にとどまっていたが、外部専門会社のフォレンジック調査完了を受けた9月15日の第二報で、顧客の個人情報7,716,811件（氏名・住所・電話番号、一部はメールアドレス・生年月日・性別）が外部へ持ち出されたことを確定した。クレジットカード情報とログインID・パスワードは別システム管理のため対象外とされ、9月15日時点で二次被害は確認されていない。個人情報保護委員会へは速報（7/20）・確報を提出し、警察へも相談している。
公開情報が限られている点について
攻撃の分類
- 侵入口
- Webアプリ脆弱性報道・研究者報道（INTERNET Watch、ScanNetSecurity）によれば、同社の第二報は『当社が管理するWebシステムの一部の脆弱性』が悪用され、そこを起点に複数のシステムへ侵入されたと説明している。脆弱性の種類（SQLインジェクション、認証回避、OSS/製品の既知脆弱性等）、自社開発か製品か、侵入日時はいずれも報道からは確認できない。なおセキュリティ対策Lab（Rocket Boys）は『具体的な侵入経路や悪用された脆弱性の有無は公式発表から確認できない』と書いており、媒体間で記述が割れている。公式ページ（pressrelease.html）は本調査時に取得できず、公式の文言は未確認のため confidence は reported とした。分類は『自社管理のWebシステム』との表現から Webアプリ脆弱性 としたが、製品・OSSの脆弱性であれば 公開サーバの脆弱性 となる可能性がある。
- 脆弱性
- CVE 非公表報道・研究者同社が管理するWebシステムの一部（製品名・種別とも非公表）第二報で『Webシステムの一部の脆弱性』を起点とされた（報道ベース）。CVE、製品名、脆弱性の種類、修正日は公表・報道とも確認できない。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- あり 7月15日未明に社内システムの障害が発生（攻撃との因果関係は公表されていない）。不正アクセス判明後、対象システムへの外部アクセスを遮断しデータ・システムを保全した。本店営業は継続。問い合わせ窓口を一本化するため公式SNSを一時休止している。通販サイトの停止有無・期間は確認できなかった。期間：社内システム障害の復旧期間は非公表。SNSの休止は2026年11月ごろ再開予定（第二報時点）
- データ
- 確定上限 7,716,811確定 7,716,811件氏名住所電話メール生年月日性別第一報（7/24）は漏えいの『痕跡』の確認にとどまり件数・持ち出し有無は調査中。第二報（9/15）でフォレンジック調査完了により7,716,811件の外部持ち出しを確定。単位は公式表記どおり『件』で、ユニークな人数かは不明（Rocket Boysの整理）。全件に含まれるのは氏名・住所・電話番号で、メールアドレス・生年月日・性別は『対象となるお客様の一部』（公式FAQの要約、Rocket Boys）。項目ごとの件数内訳は非公表。クレジットカード番号等の決済情報は別システム管理で対象外、ログインID・パスワードも対象外。
- 波及先
- —
- 金銭影響
- —
- サプライチェーン
- 委託先・取引先への波及や、委託先経由の侵入は公表・報道とも確認できない。
時系列
技術解説
攻撃の構造：Webシステムを起点にした横展開と全件持ち出し 事実
報道で伝えられた第二報の説明は、(1)同社が管理するWebシステムの一部に脆弱性があり、(2)そこを起点に複数のシステムへ侵入され、(3)顧客の個人情報7,716,811件が外部へ持ち出された、という3段階である。カード情報とログインID・パスワードは別システムで管理されていたため対象外とされ、データの分離が一部は機能した。一方で、氏名・住所・電話番号を持つ顧客台帳には、Web側の侵入点から到達できた。脆弱性の種類、侵入日、横展開に使われた手段（認証情報の窃取か、ネットワーク到達性か）、持ち出しの経路と時期はいずれも公表されていない。7月15日未明の社内システム障害が攻撃によるものかも明らかにされていない。
検知：監視ではなく障害対応で見つかった 解釈
不正アクセスは、セキュリティ監視のアラートではなく、7月15日未明の社内システム障害を復旧する過程で発見された。障害が攻撃者の操作（データの大量抽出による負荷、改ざん、暗号化の試み等）の副作用だったのか、偶然の障害で痕跡が見つかったのかは公表されていない。いずれにせよ、侵入から持ち出しまでの間にWebシステムや複数システムへの横展開を検知できていなかった可能性が高い。再発防止策として『サーバ・ネットワーク監視と侵入検知の強化』が挙げられている（ScanNetSecurity）ことも、平時の検知体制が不十分だったことを示唆する。侵入日が公表されていないため、滞留期間は評価できない。
被害が大きくなった理由：長年の顧客台帳を全件保持 解釈
持ち出しは7,716,811件で、単位は『件』である。中堅規模の家電通販事業者としては大きい数字で、長年の購入者・会員の情報を削除せず1つのデータストアに蓄積していた可能性が高い（推測）。ユニークな人数ではない可能性もあり、配送先や重複登録が件数を押し上げているかもしれない。決済情報と認証情報は分離されていたのに、氏名・住所・電話番号の顧客台帳は分離・最小化されず、Webシステムを起点とした侵入の範囲内にあった。保存期間の設定と古い顧客データの削除・匿名化をしていれば、被害母数は大幅に小さくなっていた可能性がある。
公表の評価：8日で第一報、確定まで2カ月 事実
痕跡の確認（7/16）から8日後の7/24に第一報を出し、個人情報保護委員会への速報は確認から4日後の7/20である（速報は把握から概ね3〜5日以内の目安）。件数の確定と持ち出しの事実認定には、フォレンジック調査の完了を待って約2カ月かかった。第一報の段階で件数が示されなかったため、利用者は約2カ月、自分が対象かどうか判断できなかった。また、侵入経路を『Webシステムの一部の脆弱性』と報じる媒体と、『公式発表からは確認できない』とする媒体があり、公式文面が技術的に曖昧だった可能性がある。脆弱性の種類や修正内容は示されておらず、同種のシステムを持つ事業者が教訓を引き出しにくい。
対応
- 封じ込め
- 7/16の不正アクセス確認後、対象システムへの外部アクセスを遮断し、関連データとシステムを保全。外部セキュリティ専門会社によるフォレンジック調査を実施し、9/15までに完了。再発防止策として、アクセス権限と認証情報管理の見直し、サーバ・ネットワークの監視と侵入検知の強化、定期的な脆弱性診断とセキュリティ点検を挙げている（報道）。
- 公表の仕方
- 7/24に第一報（漏えいの痕跡あり、件数・持ち出しは調査中）。9/15に第二報（7,716,811件の持ち出しを確定、対象項目、カード情報・パスワードは対象外）とFAQを公開し、対象者への個別通知メールと専用窓口を開始。問い合わせ窓口を一本化するため公式SNSを一時休止した。
- 当局対応
- 個人情報保護委員会：7/20に速報を提出、確報を提出（起点情報では9/14）
- 警察：7/23に被害相談
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| Webシステムの侵入点から顧客台帳まで到達できた | 公開Webサーバと顧客DBの間をセグメント分割し、Web層からは必要なクエリだけを許可するAPI/ストアドプロシージャ経由に限定する。DBユーザーに全件SELECT権限を与えず、1リクエストあたりの返却件数に上限を設ける |
| システム障害を復旧する過程で初めて侵害に気づいた | Webサーバ・DBのアクセスログと認証ログをSIEMに集約し、DBからの大量読み出し、深夜帯の管理系ログイン、外部への大容量転送（egress量のベースラインからの逸脱）をアラート化する。障害対応のランブックに『侵害の可能性を確認する』手順を入れる |
| 長年の顧客情報を全件保持していたため被害母数が大きくなった | 最終購入日・最終ログイン日を基準とする保存期間を定め、期限を過ぎた顧客レコードを定期バッチで削除または匿名化する。マーケティング用途の抽出は仮名化したコピーで行う |
| 決済情報・認証情報の分離は機能した | カード情報は決済代行のトークン化で自社に保持しない構成を維持し、認証情報も別DB・別資格情報で管理する。同じ考え方で、氏名・住所・電話番号を持つ個人情報ストアも独立したデータ境界として扱う |
| 侵入経路の公表が曖昧で、他社が教訓を得にくい | 公表文テンプレートに『侵入口の種別（自社開発/製品・OSS）、脆弱性の種類、修正日、侵入期間』の欄を設け、攻撃者を利さない範囲で具体的に開示する。製品の脆弱性であればJPCERT/CCやベンダーと調整して公表する |
自組織などでの確認項目
- 自社のECサイトや会員サイトのWebサーバが乗っ取られた場合、そこから顧客DBまで何ホップで到達できるか。Web層のDBアカウントは全件SELECTできるか。
- 直近のシステム障害で、原因が攻撃ではないことを確認する手順はあったか。障害対応チームとセキュリティ担当の連携はどうなっているか。
- 顧客データの保存期間を定めて実際に削除しているか。最後の購入から10年以上経つ顧客のレコードは何件残っているか。
- 痕跡は見つかったが件数は不明という段階で、自社なら何をどこまで公表するか。2カ月間『調査中』の状態を顧客はどう受け止めるか。
未解明点
- 悪用されたWebシステムの脆弱性の種類、製品名かどうか、CVE、修正日
- 侵入日と滞留期間、持ち出しの時期と経路
- 7月15日の社内システム障害と攻撃との因果関係
- 7,716,811件のユニーク人数と、項目ごとの件数内訳（メールアドレス・生年月日を含む件数）
- 横展開の手段（認証情報の窃取、共有アカウント、ネットワーク到達性など）
- 攻撃者の正体と、リークサイト掲載や販売の有無（本調査では犯行声明を確認できなかった）
出典
- 1ムラウチドットコム2026-09-15公式未確認
- 2セキュリティ対策Lab（Rocket Boys）2026-09-16報道本文確認済
- 3INTERNET Watch2026-09-16報道本文確認済
- 4ScanNetSecurity2026-10-06報道本文確認済
- 5ちんぱんブログ2026-09-18報道本文確認済
- 6SmartScope2026-10-05報道本文確認済