BASE 情報漏洩はショップサーブの件｜Eストアー不正アクセス最終報、約2,335万人・7,858店の見分け方と対応

取引先や外部サービスが入口になる攻撃の全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。本記事は、ショップサーブの件で自分が対象かどうかと、購入者・店舗・開発者がそれぞれやることに絞ります。

BASE 情報漏洩とショップサーブ不正アクセスの時系列

第一報が示した時間帯は、8月1日に不正な実行を確かめた範囲でした。翌日の第二報で、送信は5月21日から約2か月半続いていたと改められました。第一報から1日で、期間も対象の項目も広がったことになります。

何が起きたか：一つのアプリの脆弱性から7,858店分の情報が外へ

最終報によると、第三者がEストアーのサーバー上で稼働するアプリケーションの脆弱性を悪用し、不正なプログラムを実行して、データベースに格納された情報を外部へ送信しました。Eストアーは8月1日に検知して攻撃元からの通信を遮断し、脆弱性の修正と認証情報のリセットを行っています。

件数（885万件）と人数（2,335万人）の読み方

第二報の「最大延べ8,853,839件」は登録データの件数で、同じ人の複数の登録を含みうると注記されていました。最終報の「約2,335万6,000人」は、購入者・店舗運営者・アフィリエイターを集計し、重複を可能な限り除いた人数の概数です。単位が違うため、2つの数字の差から漏えいが増えた理由は読み取れません。

第二報から最終報で変わった項目

最終報から言えること、言えないこと

言えるのは、期間・人数・店舗数・項目と、二次被害の報告が無いことです。外部の専門機関の調査でもダークウェブへの流出は確認されておらず、確定した経路以外からの侵害やバックドアの設置も確認されなかったとしています。Eストアーは個人情報保護委員会と総務省関東総合通信局に報告書を出しました。

言えないのは、脆弱性の種類、店舗ごとにデータがどう分かれていたか、パスワードの保存方式の詳細です。本記事もここは推測しません。「暗号化」と「ハッシュ化」は別物ですが、最終報の文言は「暗号化されたパスワード」です。違いはパスワードのハッシュ化と暗号化の違い｜鍵ごと盗まれる保存をやめ、遅いハッシュとソルトへ移す手順を実測で解説で扱っています。

ショップサーブ 情報漏洩の対策：購入者が確かめること

自分が対象かの見分け方

ショップサーブは店舗ごとに独自のドメインや店名でサイトを作るサービスです。買った店の名前だけではショップサーブ製かどうかが分からないことがあります。手がかりは次の3つです。

・店舗またはEストアーから、本件のお詫び・お知らせのメールが届いたか
・買い物をした店舗のサイトに、本件のお知らせが出ているか
・分からなければ、自分で開いたEストアーの公式サイトの最終報から、購入者向けの相談窓口に問い合わせる

外部への送信は5月21日〜8月1日ですが、送られたのはデータベースにあった情報で、対象店舗には過去の利用店舗も含まれます。この期間に買い物をしていなくても、対象外とは限らない点に注意します。

カード情報（先頭6桁・下4桁・有効期限）で起きうること

番号の全桁とセキュリティコードは保持しておらず、漏えいしていないとされています。一方で、名義・先頭6桁・下4桁・有効期限がそろうと、本人しか知らないはずの情報を言い当てる連絡を作れます。「カードの不正利用を検知しました。下4桁が○○のカードです」と言い当てて信用させ、残りの番号やセキュリティコードを聞き出す、という形です。

・カードの利用明細を、少額の請求も含めて確かめる
・カード会社への連絡はカードの裏面にある番号に自分でかける
・Eストアーは本件でカード情報の再入力や再決済を求めず、メールや SMS でパスワードを尋ねることもないとしている

パスワードと通知を装うメール

会員IDと暗号化されたパスワードは対象です。Eストアーはパスワードが特定される可能性は低いと判断しています。それでも、同じパスワードを他のサービスで使っていれば、そちらは変えておきます。他所で漏れたパスワードが試される仕組みはリスト型攻撃の対策｜他社で漏れたパスワードで自社が破られる仕組みと、パスワード漏洩確認の実装・ログでの検知で扱っています。

お詫びや返金を装うメールにも注意します。本文のリンクから開いたページでカード番号やパスワードを入れず、店舗やEストアーのサイトは自分でブックマークか検索から開きます。

ショップサーブの店舗運営者がやること

管理画面の認証情報

第二報の時点では管理画面・メール・FTP の ID とパスワードがすべて対象とされていました。この段階では3つとも変更し、FTP で置いたファイルに覚えの無い変更が無いか、メールの転送設定が書き換えられていないかを確かめるのが筋でした。

最終報でメールと FTP は対象から外れましたが、管理画面のログインIDとパスワードは対象のままです。Eストアーは認証情報のリセットを済ませています。店舗側では次を確かめます。

・管理画面と同じパスワードを、他のサービス（メール・決済代行・広告アカウントなど）で使っていないか
・管理画面に、ログイン履歴や設定変更の履歴を見る機能があれば、5月21日以降に覚えの無い操作が無いか
・アフィリエイト登録のメールアドレスとパスワードも対象とされているので、アフィリエイターに案内が要るか

顧客への説明と個人情報保護委員会への報告

検索上位には店舗ごとのお詫びページが並んでいます。第二報の数字のまま残っていれば、最終報の内容（対象から外れた項目、カード番号の全桁は対象外、二次被害の報告は無い）にそろえます。

個人情報保護委員会の FAQ では、委託先で個人データが漏えいした場合、報告の対象になる事態なら、原則として委託元と委託先の両方が報告義務を負うとされています。委託先が委託元に通知すれば、委託先の報告義務は免除されます。各店舗が個人情報取扱事業者として報告を要するかは、自店とEストアーの契約上の関係で変わります。Eストアーの店舗向けの案内と、委員会の FAQ・ガイドラインの原文で確かめてください。

開発者・運用者向け：多テナントの教訓と自システムの確認コマンド

この件で開発者が見るべき点は2つです。一つのアプリの脆弱性から、現在と過去の7,858店に関わる情報が一度に持ち出されたこと。そして、送信が始まってから検知まで2か月半かかったことです。脆弱性の種類は公表されていないので、原因の説明はできません。以下はこの件の原因の説明ではなく、同じ形の被害を小さくするための一般的な備えです。

外部公開の棚卸しから優先順の付け方までは、IPAの不正アクセス対策を実践する手順｜外部公開・外部サービス・保有データの3つの点検、ログの見方と今日から今月の優先順で手順にしています。

ここからは自社のサーバーの確認です。どれも読み取りだけで、侵入されたかどうかの判定ではありません。

1. DB・アプリのサーバーから、社内の外へ張られた接続

DB サーバーなど、外へ出る用事が無いはずのサーバーで root として実行します（root でないと他ユーザーのプロセス名が出ません）。203.0.113. は例として置いた許可リストなので、自社の出口や連携先の範囲に置き換えます。ss は iproute2 に入っています。

ss -Htnp state established | awk '$4 !~ /^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.|203\.0\.113\.|\[::1\]|\[::ffff:127\.)/ {p=$5; sub(/^users:\(\("/, "", p); sub(/".*/, "", p); print $4, p}' | sort | uniq -c | sort -rn

出力は「接続数・相手のアドレスとポート・プロセス名」です。相手のポートが 443 などで固定なら、こちらから外へ張った接続です。相手のポートが毎回違う番号なら、外から入ってきた接続です。

2. ウェブルートの書き込み先に置かれたスクリプトと、最近変わったスクリプト

ウェブルート（例：/var/www）に移ってから実行します。1行目で表示された場所がウェブルートでなければ、先に進みません（別の場所を探してしまいます）。html/uploads は画像などのアップロード先の例なので、自分の構成に置き換えます。

cd /var/www && pwd
find html/uploads -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.jsp' -o -name '*.sh' \) -print
find . -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.jsp' -o -name '*.sh' \) -mtime -180 -print

2行目はアップロード先にはふつう置かれない種類のファイルを拾います。3行目は過去180日に変わったスクリプトを一覧にします。デプロイでも変わるので、デプロイの記録と突き合わせて、覚えの無いものを探します。日数は見たい期間に合わせて変えます。

結果の読み方とこのコマンドの限界

掲載したままのコマンドを、検証用のネットワーク名前空間とダミーのディレクトリ（一時ディレクトリをウェブルートに見立て、その下に作った html/uploads/2026/07/ と html/app/）で走らせました。

・何も出なくても侵入が無かったとは限らない：ss は実行した瞬間の接続しか見ない。送信が終わったあとや、許可リスト内の宛先・プロキシ経由の送信は出ない。find は名前と更新日時で探すので、拡張子を変えたファイルや、日時を戻したファイル、メモリ上だけで動くプログラムは出ない
・出ても侵入とは限らない：正規の外部 API・監視サービスへの接続や、デプロイで変わったファイルも拾う。宛先と変更を、構成の記録・デプロイの記録と突き合わせる

影響範囲：BASE 情報漏洩の対象はショップサーブ 対象店舗、BASE 本体は対象外

報道やまとめサイトに載った店舗名の一覧で探す場合、自分の買った店が見当たらないことは対象外の根拠になりません。確かめる手がかりは、前述の通知と相談窓口です。

参照ソース

・Eストアー 不正アクセスによる個人情報漏えいに関するお知らせ（最終報）（2026-10-16） — 期間・原因・人数・店舗数・項目・除外した項目・二次被害・報告先
・Eストアー 不正アクセスによる個人情報漏えいに関するお知らせ（第2報）（2026-08-02） — 期間の訂正・延べ8,853,839件・当時の対象項目
・Eストアー 不正アクセスによる個人情報漏えいに関するお詫びとお知らせについて（第1報）（2026-08-01） — 第一報
・BASE 当社子会社のEストアーにおける不正アクセスによる個人情報漏えいに関するお知らせ（最終報）（2026-10-16） — BASE と関係会社のサービスは別環境
・Eストアーのショップサーブへの不正アクセスについてまとめてみた（piyolog） — 第一報から第二報への変化の整理（補助）
・個人情報保護委員会 FAQ：委託先において個人データが漏えいしてしまった場合の対応 — 委託元と委託先の報告義務