---
title: "ムーンスター不正アクセス：最大59.3万人の対象店舗と、流出を半年気づけなかった検知の穴"
url: "https://www.issoh.co.jp/tech/details/18833/"
published: 2026-10-24
updated: 2026-10-24
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# ムーンスター不正アクセス：最大59.3万人の対象店舗と、流出を半年気づけなかった検知の穴

靴メーカーのムーンスターは2026年10月15日、オンラインストアを利用した最大59万3千人の氏名・住所・電話番号・メールアドレス・過去の注文情報が漏えいした可能性があると公表しました。同社は3月に不正アクセスを認識して公表していましたが、情報が持ち出されたのはその後の5月14日から19日にかけてと見られています。本記事の前半は、公式の第1〜3報から対象の店舗・項目・経緯を整理し、注文内容が書かれた偽メールを受け取った利用者の対処をまとめました。後半は開発者とEC事業者に向けて、流出を顧客からの問い合わせより先に見つけるための、おとり顧客レコードとデータベースの読み出し監視をコード付きで示します。

## まとめ：ムーンスター不正アクセスで公表された範囲と利用者がいま行うこと

漏えいの可能性があるのは、楽天市場やYahoo!ショッピングを含む8つの店舗で買い物をした利用者の情報です。クレジットカード情報とECサイトのログインパスワードは、対象のサーバーに保存されていなかったため含まれていません。

| 項目      | 公表内容（2026年10月15日の第3報） |
| ------- | --------------------- |
| 対象人数    | 最大59万3千人              |
| 漏えいの可能性 | 氏名・住所・電話番号・メール・注文情報   |
| 対象外     | カード情報・ログインパスワード       |
| 流出の時期   | 2026年5月14日〜19日の可能性が高い |
| 判明の経緯   | 9月20日前後の顧客からの問い合わせ    |
| 対象者への連絡 | 順次個別メール（連絡が無ければ対象外）   |

利用者がまず行うのは、ムーンスターを名乗るメールやSMSのリンクを開かないことです。偽メールには本物の注文内容が書かれている場合があり、内容の正しさは本物の証拠になりません。気になる連絡は、公式サイトに載っているカスタマーセンター（0800-800-1792・平日10〜17時）へ自分から確かめます。

## 公式第1〜3報で確かめるムーンスター不正アクセスの対象店舗・項目・経緯

### 楽天・Yahoo!・閉店済みのAmazonを含む8店舗と最大59万3千人の対象

[ムーンスターの第3報](https://www.moonstar.co.jp/information/2026/10/gg.html)が対象として挙げたのは、次の8店舗です。

- 楽天市場 ムーンスター公式ショップ
- Yahoo!ショッピング ムーンスター公式ショップ
- MOONSTAR ONLINE STORE
- MOONSTAR LIFESTYLE EC STORE
- au PAYマーケット ムーンスター公式ショップ
- ムーンスター アウトレット
- Qoo10 ムーンスター公式ショップ（閉店）
- Amazon ムーンスター公式ショップ（閉店）

自社サイトだけでなく、モールに出店した店舗の購入者も含まれます。すでに閉じた2店舗も対象に入っている点は、後半の章で扱う「受注データをどこまで持つか」という論点にも関わる事実です。最大59万3千人は対象になりうる人数の上限で、ムーンスターは該当者に順次メールで個別に連絡するとしています。

### 氏名・住所・電話・メール・注文情報と、カード番号が対象外の理由

漏えいの可能性があるのは、氏名、住所、電話番号、メールアドレス、過去の注文情報の5つです。第3報は、この範囲が[10月2日の第2報](https://www.moonstar.co.jp/information/2026/10/post-4.html)と同じだと明記しました。

クレジットカード情報とECサイトのログインパスワードが対象外なのは、狙われたサーバーにそもそも保存されていなかったからです。持っていない情報は漏れない、という分かりやすい例です。

逆に、注文情報が漏れた意味は小さくありません。いつ、どの商品を、どこへ届けたかが分かると、受け取った本人しか知らないはずの内容でメールを書けるからです。

### 3月26日の初報から5月の流出、9月の問い合わせで判明するまでの経緯

3回の公表を並べると、認識・流出・判明の順序がはっきりします。

| 日付             | 出来事                       |
| -------------- | ------------------------- |
| 2026年3月26日     | 第1報。不正アクセスの疑いを公表、情報取得は未確認 |
| 2026年5月14日〜19日 | サーバー経由で個人情報が漏えいした可能性が高い期間 |
| 2026年9月20日前後   | 注文情報入りの偽メールについて顧客から問い合わせ  |
| 2026年10月2日     | 第2報。漏えいの可能性と項目を公表         |
| 2026年10月15日    | 第3報。8店舗・最大59万3千人・流出期間を公表  |

[3月の第1報](https://www.moonstar.co.jp/corporate/news/archive/post-74.html)の時点では、顧客の情報が不正に取得された事実は確認されていないとされていました。流出の可能性が高い5月は、その約2か月後です。そして漏えいに気づいたきっかけは、社内の監視ではなく顧客からの問い合わせでした。不正アクセスの具体的な手法、対象システム、脆弱性は、再発防止のため記載を差し控えるとされています。

## 注文内容入りの偽メールを受け取った利用者が確かめる手順と相談先

### 本物の注文内容が書かれたメールでも利用者が本物とは判断できない理由

第3報によると、顧客に届いたなりすましメールには、顧客とムーンスターしか知りえない過去の注文情報が書かれていました。これまでの偽メール対策では「自分の名前や注文内容が正しく書かれていれば本物」と考えがちでしたが、この事案ではその判断が通用しません。

確かめる材料にするのは、内容ではなく行動の要求です。ムーンスターは、メール・SMS・電話でパスワードやクレジットカード情報を尋ねることは無いと明言しています。支払いのやり直し、カード情報の再入力、アカウントの確認を求めるメールは、注文内容が正しくても開かずに削除してかまいません。送信元を詐称するメールの手口の全体像は[フィッシングの手口と見分け方](https://www.issoh.co.jp/column/details/13262/)で整理しています。

### 個別メールを待つ間に、購入した店舗の注文履歴から確かめる方法

ムーンスターは、漏えいの可能性がある利用者へ順次メールで連絡し、連絡が無い場合は対象外としています。ただし、このお詫びメールを装った偽メールが出回る余地もあります。お詫びメールのリンクから何かを入力する手順は、公表文には書かれていません。

自分が対象かどうかの見当は、手元で付けられます。楽天市場やYahoo!ショッピングで買った場合は、そのモールの購入履歴にムーンスター公式ショップの注文があるかを、ブックマークやアプリから開いて確かめます。閉店したAmazonとQoo10の店舗で買った記録も対象に入る点に注意してください。購入履歴があり、不審なメールやSMSが届いている人は、カスタマーセンターの電話（0800-800-1792）かメール窓口に相談します。

### 偽メールに入力してしまったときのカード会社への連絡と変更の順番

偽メールのリンク先でカード番号を入力した場合は、カード会社への連絡が最優先です。カードの利用停止と再発行を頼み、明細に覚えのない請求が無いかを確かめます。ムーンスターのサーバーにはカード情報が無かったため、入力さえしていなければこの手順は要りません。

パスワードを入力した場合は、そのパスワードを使っているサービスをすべて変えます。モールのアカウントと同じパスワードを他でも使っていれば、そちらが先に狙われるおそれもあるためです。住所と電話番号が知られたことによる不審な電話や郵便物には、折り返しの番号を相手に聞かず、公式サイトの番号へかけ直して確かめます。

## 3月の認識から5月の流出まで止められなかった構造とEC事業者の初動

### 「情報取得の事実は未確認」という初報が意味していた調査・確認の範囲

第1報の「顧客の情報が不正に取得された事実は確認されていない」は、その時点で見えていた記録の中に痕跡が無かった、という意味です。痕跡を残さない読み出しや、記録を取っていない経路からの持ち出しは、この確認の外にあります。第3報が流出期間を5月と特定できたのは、9月に顧客の問い合わせという外部からの手がかりを得て、調査をやり直した結果です。

第2報と第3報は、対応として外部接続の遮断とパスワードの強制変更を挙げています。ただ、それを3月の認識直後に行ったのか、9月の判明後に行ったのかは、公表文から読めません。EC事業者が自社の初動に置き換えるなら、認識した時点で「攻撃者が使えた認証情報をすべて失効させたか」と「その後の読み出しを記録しているか」の2点を、漏えいの有無とは別に確かめることになります。

### 閉店した店舗の受注データまで1か所に残る多店舗運営の保管範囲

対象の8店舗には、すでに閉店したAmazonとQoo10の店舗が含まれます。閉店した店舗の購入者の情報が漏えいの対象に入ったということは、その受注データが2026年5月の時点でも、狙われたサーバーから読める位置に残っていたと考えられます。

モールごとの受注を1つの受注管理システムに集めると、出荷や問い合わせ対応は楽になります。その反面、1台のサーバーに全店舗の顧客台帳ができあがり、閉じた店舗や古い注文の分も削除されないまま積み上がりやすい構造です。出荷と返品の対応が終わった注文から、住所や電話番号を消すか別の保管先へ移す期日を決めておけば、同じ侵入でも漏れる件数は減ります。保存期間と削除の設計は[顧客情報管理システムの保存期間と削除の要件](https://www.issoh.co.jp/column/details/18264/)で、移行後に旧データが残って漏れた事例は[PFUの移行済みEC基盤に残る旧データ](https://www.issoh.co.jp/tech/details/18176/)で扱いました。

## 受注データの流出を顧客からの問い合わせより先に見つける検知の実装

### 店舗ごとのおとり顧客レコードで流出元を特定するPythonスクリプト

ムーンスターの事案で漏えいに気づかせたのは、注文情報入りの偽メールでした。同じ仕組みを事業者側が先に仕掛けておく方法があります。実在しない「おとり」の顧客を、自社だけが受信できるメールアドレスで受注データに混ぜておき、そのアドレスにメールが届いたら流出の兆候と判断する手法です。アドレスを店舗ごとに分けておけば、どの保管先から漏れたかまで絞れます。

```
import csv
import secrets
import sys
from datetime import date

# おとり専用ドメイン（このドメイン宛てに届くメールは、すべて漏えいの兆候として扱う）
CANARY_DOMAIN = "canary.example.jp"
# 受注データの出どころ（店舗・保管先）ごとにおとりを分けて入れる
CHANNELS = ["rakuten", "yahoo", "own_store", "outlet"]


def make_rows(per_channel=2):
    rows = []
    for ch in CHANNELS:
        for _ in range(per_channel):
            token = secrets.token_hex(4)
            rows.append({
                "channel": ch,
                "token": token,
                "email": f"{ch}-{token}" + "@" + CANARY_DOMAIN,
                "created": date.today().isoformat(),
            })
    return rows


def lookup(registry, rcpt):
    # 届いたメールの宛先から、どの保管先のおとりかを引く
    token = rcpt.split("@")[0].rsplit("-", 1)[-1]
    return next((r for r in registry if r["token"] == token), None)


if __name__ == "__main__":
    if sys.argv[1] == "make":
        rows = make_rows()
        with open("canary_registry.csv", "w", newline="", encoding="utf-8") as f:
            w = csv.DictWriter(f, fieldnames=rows[0].keys())
            w.writeheader()
            w.writerows(rows)
        print(len(rows), "件のおとりを canary_registry.csv に保存")
    elif sys.argv[1] == "check":
        with open("canary_registry.csv", encoding="utf-8") as f:
            hit = lookup(list(csv.DictReader(f)), sys.argv[2])
        if hit:
            print("漏えい元の候補:", hit["channel"], "/ 投入日", hit["created"])
        else:
            print("台帳に無い宛先")
```

`python canary_rows.py make`で店舗ごとに2件ずつ、計8件のおとりを作り、台帳のCSVに残します。生成したアドレスを、それぞれの店舗の受注データとして受注管理システムに登録してください。おとり用ドメインに届いたメールの宛先を`python canary_rows.py check <届いた宛先>`に渡すと、店舗名と投入日が返ります。本記事ではPython 3.14.7で生成と照合を実行し、台帳にある宛先は店舗名を、無い宛先は「台帳に無い宛先」を返すことを確かめました。乱数は推測されにくい値を作る標準モジュール`secrets`で発行しています。

運用で気をつけるのは2点です。おとりの名前や住所が実在の人物と重ならないこと、そして出荷や販促メールの対象から外すことです。おとりに自社からメールを送ってしまうと、届いたメールが流出の兆候なのか自社の配信なのか区別できなくなります。

### pg\_stat\_statementsの差分でデータベースの大量読み出しを見つけるSQL

おとりは「漏れたあと」に気づく仕組みです。持ち出しの最中に気づくための監視対象は、データベースの読み出し量です。PostgreSQLなら拡張機能[pg\_stat\_statements](https://www.postgresql.org/docs/current/pgstatstatements.html)が、SQLごとの実行回数（`calls`）と、取得または変更した行数の累計（`rows`）を記録します。累計値なので、一定間隔で写しを取り、その差分で急な増加を探します。

```
-- postgresql.conf の shared_preload_libraries に pg_stat_statements を加えて再起動したあと
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- 写しを保存する表（5分ごとにジョブで INSERT する）
CREATE TABLE IF NOT EXISTS stmt_snapshot (
  taken_at timestamptz NOT NULL DEFAULT now(),
  userid oid, dbid oid, toplevel boolean, queryid bigint,
  calls bigint, rows bigint
);

INSERT INTO stmt_snapshot (userid, dbid, toplevel, queryid, calls, rows)
SELECT userid, dbid, toplevel, queryid, calls, rows FROM pg_stat_statements;

-- 直近2回の写しの差分で、その間に読んだ行数が多いSQLを並べる
WITH t AS (
  SELECT DISTINCT taken_at FROM stmt_snapshot ORDER BY taken_at DESC LIMIT 2
),
cur AS (SELECT * FROM stmt_snapshot WHERE taken_at = (SELECT max(taken_at) FROM t)),
prev AS (SELECT * FROM stmt_snapshot WHERE taken_at = (SELECT min(taken_at) FROM t))
SELECT r.rolname, cur.queryid,
       cur.rows - coalesce(prev.rows, 0)   AS rows_in_window,
       cur.calls - coalesce(prev.calls, 0) AS calls_in_window
FROM cur
LEFT JOIN prev USING (userid, dbid, toplevel, queryid)
JOIN pg_roles r ON r.oid = cur.userid
WHERE cur.rows - coalesce(prev.rows, 0) > 50000
ORDER BY rows_in_window DESC;
```

しきい値の50000行は説明用の値です。平日の受注処理で出る行数を1〜2週間記録してから、その数倍に置きます。公式ドキュメントのとおり、この拡張は共有メモリを使うため、`shared_preload_libraries`への追加にはサーバーの再起動が要ります。他のロールが実行したSQLの本文と`queryid`を見られるのは、スーパーユーザーと`pg_read_all_stats`の権限を持つロールだけです。監視用のロールにはこの権限を付け、アプリのロールとは分けます。

統計が途中でリセットされると差分が負の値になり、記録できるSQLの数の上限（`pg_stat_statements.max`）を超えると古い行が入れ替わります。差分が負のときは警告を出さずに次の写しを待つ、という分岐をジョブ側に入れてください。上のSQLは本記事の環境では実行しておらず、PostgreSQL 18の公式ドキュメントの列定義に基づく記載です。

### おとりと読み出し監視の導入を見送る事業者の条件と、先に塞ぐ侵入口

2つの仕組みを入れる価値が大きいのは、複数の店舗の受注を1つのデータベースに集め、数十万人規模の顧客台帳を持つ事業者です。逆に、受注データをモールの管理画面とカートサービスの中だけで扱い、自社でデータベースを持たない事業者には過剰です。その場合はモールのアカウントの多要素認証と、管理画面に入れる担当者の棚卸しを先に済ませます。

どちらも検知の仕組みで、侵入そのものは防ぎません。順番としては、外部から届く入口の認可とレート制限が先です。APIや管理画面の入口を固める手順は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)にまとめました。自社の受注管理システムがどこまで読める状態にあるか、監視がどこに足りないかを外部の目で点検するなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。

## よくある質問

ムーンスターの不正アクセスについて、オンラインストアの利用者から出やすい質問をまとめました。

### ムーンスターの不正アクセスで自分が対象かはどう確かめればよいですか？

ムーンスターは、漏えいの可能性がある利用者へ順次メールで個別に連絡し、連絡が無い場合は対象外としています。対象は楽天市場・Yahoo!ショッピング・自社EC・au PAYマーケット・アウトレットなど8店舗の利用者です。購入したモールの注文履歴にムーンスター公式ショップの注文があるかを、メールのリンクではなくブックマークやアプリから確かめると見当が付きます。

### クレジットカード番号は漏れましたか？

漏れていないとされています。第3報によると、クレジットカード情報とECサイトのログインパスワードは対象のサーバーに保存されておらず、今回の事案には含まれていません。ただし、偽メールのリンク先でカード番号を入力した場合は別の被害になるため、すぐにカード会社へ連絡して利用停止を頼んでください。

### 楽天市場やAmazonのムーンスター公式ショップで買った場合も対象ですか？

対象です。第3報は、楽天市場とYahoo!ショッピング、au PAYマーケットの公式ショップを対象に挙げています。現在は閉店しているAmazonとQoo10の公式ショップも含まれます。閉店前に買った記録がある人も、不審な連絡に注意してください。

### 注文内容が正しく書かれたメールは本物ですか？

本物とは限りません。第3報では、顧客とムーンスターしか知らない過去の注文情報を記載したなりすましメールが確認されています。ムーンスターはパスワードやカード情報をメール・SMS・電話で尋ねないと明言しているため、これらを求める連絡には応じず、公式サイトに載っている窓口（0800-800-1792）へ確かめます。

### ムーンスターの不正アクセスの原因は何ですか？

10月24日時点で、不正アクセスの具体的な手法、対象システム、脆弱性は、再発防止と安全確保のため記載を差し控えるとされています。公表されているのは、3月に認識したこと、5月14日〜19日に流出した可能性が高いこと、個人情報保護委員会へ報告したことです。報告の考え方は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)と[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)で確かめられます。

## 関連記事

- [PFUの不正アクセスと最大16万件の注文データ漏えい｜移行済みEC基盤に残る旧データの消去設計](https://www.issoh.co.jp/tech/details/18176/)：EC の古い注文データが残って漏れた別の事例
- [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効](https://www.issoh.co.jp/tech/details/18346/)：受注システムへの侵入口を塞ぐ対策
- [顧客情報管理システムの要件｜個人情報保護法の安全管理措置・保存期間・削除を設計に落とす【2026年版】](https://www.issoh.co.jp/column/details/18264/)：顧客台帳の保存期間と削除の設計
- [フィッシング対策ガイドライン2026年度版のDMARC要件｜p=reject推奨の中身とnoneからの移行手順](https://www.issoh.co.jp/tech/details/12369/)：自社ドメインを詐称されにくくする設定
- [情報漏洩対策とは：原因別4類型の防ぎ方と発生時の報告義務【2026年10月版】](https://www.issoh.co.jp/column/details/18315/)：漏えいの防ぎ方と発生時の報告

---

出典: [ムーンスター不正アクセス：最大59.3万人の対象店舗と、流出を半年気づけなかった検知の穴](<https://www.issoh.co.jp/tech/details/18833/>)（株式会社一創）