ムラウチドットコムで情報漏洩、個人情報771万件の外部持ち出しを確認
| 項目 | 内容 |
|---|---|
| 発生日 | 2026年7月15日未明にシステム障害として顕在化／翌16日の復旧作業中に不正アクセスの痕跡を確認 |
| 公表日 | 第一報: 2026年7月24日／第二報: 2026年9月15日 |
| 対象組織・業界 | 株式会社ムラウチドットコム（東京都八王子市北野町／ECサイト「murauchi.com」やモール店舗を運営するインターネット通信販売事業、「にほんブログ村」等のインターネットメディア事業） |
| 影響件数 | 771万6,811件（氏名、住所、電話番号、メールアドレス、生年月日、性別）。クレジットカード情報とパスワードは含まれていないと説明されている |
| 攻撃手法 | Webシステムの一部に存在した脆弱性の悪用を起点とする、複数システムへの不正アクセスとデータの外部持ち出し |
| 情報源 | 株式会社ムラウチドットコム 第二報（2026年9月15日）、ITmedia NEWS（2026年9月17日）、INTERNET Watch（2026年9月17日）、ASCII.jp（2026年9月17日）、Security NEXT（2026年9月17日） |
株式会社ムラウチドットコム（東京都八王子市北野町／インターネット通信販売・インターネットメディア事業）は2026年9月15日、同年7月に一部システムで確認された不正アクセスについて第二報を公表しました。外部のセキュリティ専門会社によるフォレンジック調査が完了し、771万6,811件の個人情報が漏えいしていたことが確認されたとしています。
漏えいが確認されたのは、氏名、住所、電話番号、メールアドレス、生年月日、性別です。クレジットカード情報とパスワードは含まれていないと説明されています。7月24日の第一報では「漏えいした可能性」という表現にとどまり、件数も示されていませんでしたが、約2か月の調査を経て件数が確定し、外部への持ち出しがあったことも確認された形です。
侵入の起点は、Webシステムの一部に存在していた脆弱性でした。攻撃者はそこを突いて侵入したあと、複数のシステムへ不正にアクセスしています。同社は9月14日に個人情報保護委員会へ確報を提出し、翌15日から対象となる顧客への個別の通知メールの送信を順次開始しています。
- 2026年7月15日未明: システム障害を確認
- 2026年7月16日: 復旧作業を進める中で不正アクセスの痕跡を確認
- 2026年7月20日: 個人情報保護委員会へ速報を提出
- 2026年7月23日: 警察へ被害を相談
- 2026年7月24日: 第一報を公表。氏名、メールアドレス、住所、電話番号、および一部の対象者について生年月日と性別が漏えいした可能性があるとした。この時点では件数も侵入経路も示されていない
- 2026年9月14日: 個人情報保護委員会へ確報を提出
- 2026年9月15日: 第二報を公表。外部のセキュリティ専門会社によるフォレンジック調査の完了を受け、漏えいが確認された件数を771万6,811件と明らかにした。同日から対象顧客への個別の通知メールの送信を順次開始
Webシステムの一部に存在していた脆弱性を悪用されたことが起点であると公表されています。攻撃者はそこを足がかりに、複数のシステムへ不正アクセスしています。
悪用された脆弱性が自社で開発した部分のものか、利用していた製品やライブラリのものか、また具体的な名称と公表時期は公表されていません。攻撃者がいつ侵入し、どれだけの期間システム内にとどまっていたかも示されていません。
影響を受けた情報
Section titled “影響を受けた情報”- 件数: 771万6,811件
- 種類: 氏名、住所、電話番号、メールアドレス、生年月日、性別
- 含まれていないとされるもの: クレジットカード情報、パスワード
同社は再発防止策として、システムへのアクセス権限や認証情報の管理を含むセキュリティ対策の見直しを進めており、今後も定期的な脆弱性診断とセキュリティ点検を実施して潜在的な問題を早期に把握するとしています。
1. 使っているソフトウェアの脆弱性情報を、自社のどの資産に当たるのかまで突き合わせて追う
Section titled “1. 使っているソフトウェアの脆弱性情報を、自社のどの資産に当たるのかまで突き合わせて追う”侵入の起点となったのは、公開していたWebシステムの脆弱性です。脆弱性の公表を眺めているだけでは、自社のどのサーバー・どのアプリケーションが該当するのかは分かりません。稼働中のWebシステムについて、使用しているフレームワーク・ライブラリ・ミドルウェアとそのバージョンを一覧にしておき、公表された脆弱性を毎回その一覧に突き合わせます。これで自社に該当するかどうかを調べる時間を短縮でき、修正までの日数をその分だけ縮められます。
2. 更新が終わるまでの時間を、入口側の対策で持たせる
Section titled “2. 更新が終わるまでの時間を、入口側の対策で持たせる”脆弱性が公表されてから修正の適用が完了するまでには、検証と切り替えの時間が必ずかかります。その間を無防備にしないために、管理画面のアクセス元をあらかじめ決めたIPアドレスに限定する、管理者アカウントに多要素認証を必須にする、WAFで既知の攻撃パターンを遮断するといった入口側の措置を平常時から効かせておきます。修正が間に合わない期間があっても、攻撃者が実際に到達できる範囲を狭められます。
3. Webシステムから他システムへ渡れる認証情報とアクセス権限を絞る
Section titled “3. Webシステムから他システムへ渡れる認証情報とアクセス権限を絞る”本件では、1つの脆弱性を起点に複数のシステムへアクセスが広がりました。Webシステムが動くサーバーに、他システムへ接続するための認証情報が置かれていれば、そこを取られた時点で接続先も同時に危険にさらされます。Webシステムが保持する接続情報を洗い出し、参照だけで足りる接続に更新権限を与えない、システムごとに別の認証情報を使う、といった形で権限を切り分けておきます。これにより、最初に侵入されたシステムから先へ進む手間が攻撃者側に発生します。
ヤグラの視点 — 侵入から771万件の持ち出しまでに、止められる段はいくつもあった
Section titled “ヤグラの視点 — 侵入から771万件の持ち出しまでに、止められる段はいくつもあった”入口は1つの脆弱性でしたが、771万件が外部へ出るまでには段がいくつもありました。公開Webシステムへの攻撃、侵入後の他システムへの接続、そして大量のデータの読み出しと外部への送信です。それぞれは別のシステムで起き、別のログに痕跡を残します。
異変が表に出たのは7月15日未明のシステム障害でした。攻撃が業務に影響するところまで進んで、ようやく気づける状態だったことになります。攻撃の各段は、Webサーバーのアクセスログ、サーバー間の認証ログ、データベースの監査ログにそれぞれ記録されているはずですが、1つひとつを取り出すと正常な処理と見分けがつきにくいものです。普段は数十件しか読まないテーブルから数百万件が読み出されたという事実は、その読み出しを平常時の量と比べて初めて浮かび上がります。
まず、どのシステムのどのログを取得して、どこへ集めるのかを決めておきます。公開Webシステムのアクセスログ、サーバーとデータベースの認証ログ、外部への通信ログを1か所に集約し、平常時の量と時間帯を把握しておけば、そこからの逸脱を比較対象のある形で捉えられます。そのうえで、集めたログを人手ではなくAIで24時間365日横断的に監視することで、検知から初動までを数分の単位に縮められます（→ ヤグラ AI SOC）。
- 悪用された脆弱性の具体的な内容と、その公表時期
- 攻撃者が最初に侵入した時期と、システム内にとどまっていた期間
- 漏えいした情報を使ったなりすましメールやフィッシングなど、二次被害の発生状況
- 見直しを進めているとされるアクセス権限・認証情報の管理について、具体的な内容が示されるかどうか
- 個人情報保護委員会による確報受理後の対応
判明次第、本記事に追記します。
| 日時 | 内容 |
|---|---|
| 2026-07-28 | 過去アーカイブとして記事化（キュレーション） |
| 2026-09-18 | 第二報（2026-09-15公表）を反映。漏えい件数を771万6,811件と確定、漏えい情報の種類を更新、原因をWebシステムの脆弱性の悪用と明記。severity を medium から critical、status を investigating から resolved に変更 |
