Eストアー情報漏洩はなぜ起こったのか｜事実から見える構造的な問題と再発の背景

情報漏洩・セキュリティ事故まとめ

2026.10.16

はじめに

2026年に発生したEストアー（BASE子会社）の情報漏洩は、 2335万人という国内最大級の規模で、多くの利用者・店舗に影響を与えました。

本記事では、公式発表やフォレンジック調査で判明している事実を整理しながら、その流れの中で自然に浮かび上がる「構造的な問題」について解説します。

ニュース的な淡々とした説明ではなく、事実を踏まえたうえで、どこに課題があったのかを丁寧に掘り下げていきます。

1．侵入経路はアプリケーションの脆弱性

公式発表によれば、攻撃者は アプリケーションの脆弱性を悪用して侵入 しています。

この流れは、典型的な「脆弱性悪用型の攻撃」です。

脆弱性の種類は公表されていませんが、ゼロデイのような特殊なものではなく、一般的な診断で発見できる可能性が高いタイプだったと考えられます。

ECプラットフォームは機能追加が優先されやすく、セキュリティ改善が後回しになることが多いため、脆弱性が長期間残ってしまうケースは珍しくありません。今回の事件も、その構造的な弱点が影響した可能性があります。

攻撃期間は 2026年5月21日〜8月1日（約72日間）。この間、攻撃者はサーバー内部で不正プログラムを継続的に実行していました。

不正なプロセスが2ヶ月以上動作していたという事実は、監視体制の弱さを示す重要なポイントです。

攻撃者は大量データを一度に送信するのではなく、小分けで静かに送信していた可能性が高く、こうした「静かな攻撃」は監視の粒度が粗い環境では見逃されやすい傾向があります。

ECプラットフォームは夜間・休日の監視が弱いケースも多く、今回の長期化は、運用面の隙を突かれた結果とも言えます。

フォレンジック調査では、バックドア（恒久的な侵入口）は確認されていません。

これは一見すると安心材料ですが、脆弱性が修正されるまで攻撃者が自由に出入りできた状態だったことを意味します。

バックドアがなかったというより、脆弱性そのものが“バックドアの役割”を果たしていたと言えます。

長期間気づけなかったことから、以下のような運用面の課題が推測されます。

特に、「不正プログラムが正規プロセスに偽装していた可能性」「外部送信が少量で断続的だった可能性」などを踏まえると、静かな攻撃に対して検知が機能していなかったと考えられます。

監視体制が十分であれば、不正なDBアクセスや不審な通信は早期に検知できるため、今回のような長期化は起こりにくいはずです。

Eストアーは以下の対策を実施しています。

ただし、再発防止策の内容は「必要最低限」に留まっており、監視体制の具体的な改善内容や、脆弱性診断の頻度がどれほど増えたのかなど、根本的な部分が明確ではありません。

再発防止策は「実施したこと」よりも どれだけ継続できるか が重要であり、現時点では不透明な点が多い印象です。

事実を整理すると、今回の漏洩は以下の要因が重なって発生しています。

これらを踏まえると、今回の漏洩は単なる「巧妙な攻撃」ではなく、 防御側の構造的な弱点が積み重なって起きた事故 と捉えるべきだと考えられます。