セキュリティ

ミスターマックスの不正アクセスと最大173万人の流出｜サーバーの公開機能を点検する手順

ミスターマックスの不正アクセスと最大173万人の流出｜サーバーの公開機能を点検する手順

ミスターマックスは2026年10月6日、MrMaxアプリとオンラインストアのサーバーが第三者による不正アクセスを受け、会員の個人情報の一部が外部に流出したと公表しました。対象は最大1,735,154人で、流出した情報は会員ID、氏名、メールアドレス、電話番号です。公表の中で目を引くのは、侵入の方法を「本サービスを構成するソフトウェアの機能を不正に利用して」と表現している点です。本記事では、公式発表から確定できる事実を整理します。そのうえで、アプリやECサイトを運営する側が、自社のサーバーで外に開いたままの機能がないかを確かめる手順を、手元で動くPythonスクリプトと設定例で示します。

まとめ：ミスターマックスの不正アクセスで公表された事実と運営側の点検

確定している事実は次のとおりです。2026年10月3日（土）の夕方に、サーバーへの不審なアクセスが見つかりました。同社はただちにサービスを一時停止し、同日中に外部からのアクセスを遮断しています。流出したのはMrMaxアプリ会員とオンラインストア会員の会員ID、氏名、メールアドレス、電話番号で、住所、生年月日、クレジットカード情報、パスワード、購入履歴は流出していないと確認されました。

侵入に使われたソフトウェアの名前や、どの機能が使われたかは公表されていません。そのため原因は断定できません。それでも「ソフトウェアの機能を不正に利用」という言い方は、運営側に一つの問いを突きつけます。自社のサーバーを構成するソフトウェアのうち、外から呼べる機能をすべて把握しているか、です。管理用の画面や診断用の窓口が、利用者向けの入口と同じ場所に開いていないかを、まず外から確かめてください。

項目 公表されている内容
不審なアクセスの確認 2026年10月3日（土）夕方
初動 即時の一時停止・同日中に遮断
公表日 2026年10月6日
対象人数 最大1,735,154人
流出した情報 会員ID・氏名・メール・電話番号
流出していない情報 住所・生年月日・カード・PW等
侵入の方法 構成ソフトウェアの機能の不正利用
報告・相談先 個人情報保護委員会・警察

公式発表で事実を確かめる｜10月3日の不審なアクセスから6日の公表まで

10月3日夕方の発覚から同日中の遮断までと公表の文面で分かること

ミスターマックスのお知らせ（2026年10月6日）によると、10月3日（土）の夕方に当社サーバーへの不審なアクセスを確認しました。発覚後ただちにサービスを一時停止し、同日中には外部からのアクセスを遮断する措置を取っています。発覚から遮断までが同じ日のうちに収まっています。

その後の調査で、第三者が本サービスを構成するソフトウェアの機能を不正に利用してサーバーに侵入し、会員の個人情報の一部が流出したことが分かりました。公表は発覚から3日後の10月6日です。同じ内容のPDFも公開されています。お知らせには、サービスの再開時期は書かれていません。

最大1,735,154人と流出した4項目・登録状況で項目が変わる注記の意味

対象はMrMaxアプリ会員とオンラインストア会員で、人数は最大1,735,154人です。数え方は「2026年10月3日時点で会員登録されているお客様」とされています。流出した情報は会員ID、氏名、メールアドレス、電話番号の4項目です。

注記として、お客様の登録状況によって流出の対象となる情報は異なると書かれています。アプリだけの会員とオンラインストアの会員では、登録している項目が違うためと読めます。「最大」とあるのも同じ理由で、全員の4項目がそろって流出したという意味ではありません。住所、生年月日、クレジットカード情報、パスワード、購入履歴は流出していないと確認されています。

1週間前のセイコーマート事案と比べて分かる公表内容の違いと共通点

小売の会員アプリが狙われた事案としては、1週間前にセイコーマートの不正アクセスと57万人の会員情報が公表されたばかりです。両者を公表内容で並べると、違いがはっきりします。

比較項目 ミスターマックス セイコーマート
対象人数 最大1,735,154人 572,022人
流出項目の数 4項目 8項目
住所・生年月日 流出していない 閲覧の対象
手法の公表 構成ソフトの機能の不正利用 非開示
発見のきっかけ 不審なアクセスの確認 不正な退会処理1件

人数はミスターマックスが約3倍ですが、項目は半分で、住所と生年月日を含みません。一方で、どちらも氏名、メールアドレス、電話番号がそろって流出しています。利用者にとっての当面の危険は、本物らしく見えるメールやSMSが届くことである点で共通します。

会員と利用者が今やること｜SMSと電話のなりすましと送信元ドメイン

同社は、流出した情報を悪用した被害は公表時点で確認されていないとしたうえで、なりすましメールやフィッシングメールが届く可能性を挙げています。同社や関係者を名乗るメール、SMS、電話、郵便物にも注意を呼びかけ、パスワードやクレジットカード番号を尋ねることはないと明言しました。電話番号が流出しているため、メールよりSMSと電話の方が警戒の優先度は高いと考えます。

対象者には、同社からお詫びのメールが個別に届きます。送信元はmrmax.jpドメインのアドレスと案内されており、公式サイトのmrmax.co.jpとはドメインが異なります。届いたメールの送信元が案内どおりかを確かめ、本文のリンクは開かずに公式サイトから入り直すのが安全です。同じメールアドレスとパスワードを他のサービスで使い回している場合は、そちらを変えておくと安心です。手口の見分け方はフィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策で解説しています。

「ソフトウェアの機能を不正に利用」から読める論点と推測しない範囲

公表語が脆弱性ではなく機能と書いている点から確定できることの範囲

ソフトウェアを使った侵入と聞くと、脆弱性を突かれたと受け取りがちです。しかし公式の発表は、脆弱性という言葉を使っていません。書かれているのは「本サービスを構成するソフトウェアの機能を不正に利用して」です。本記事は公式の表現に合わせ、脆弱性と断定しません。

この表現に当てはまる状態は複数あります。本来は社内だけで使う管理機能や診断機能が外から呼べた場合、設定の誤りで想定外の操作が許されていた場合、ソフトウェアの欠陥を突かれた場合のいずれもあり得ます。どれだったかは、外部の専門機関による調査の結果を待つしかありません。運営側にとって意味があるのは、自社で同じ三つの状態が起きていないかを確かめることです。

外部から呼べる管理機能が情報流出の経路になる典型的なサーバー構成

Webアプリケーションのフレームワークやミドルウェアには、運用を助ける機能が最初から入っています。稼働状況の確認、設定値の表示、メモリの中身の書き出し、API仕様書の表示などです。これらは社内の監視や開発のためのもので、利用者には不要です。

例えばJavaのSpring Boot Actuatorの公式ドキュメント（2026年10月7日時点で4.1系）は、既定でHTTPに公開されるのはhealthだけだと明記しています。そのうえで、公開範囲を広げる前に、機密情報を含まないか、ファイアウォールの内側にあるか、Spring Securityなどで守られているかを確かめるよう求めています。メモリの中身を返すheapdumpには、接続中のデータベースのパスワードや処理中の会員情報が入り得るためです。公開設定の詳細はSpring Boot Actuatorの使い方にまとめています。

OWASP API8とAPI9で整理する設定の誤りと構成の把握漏れ

この種の問題は、OWASP API Security Top 10 2023のAPI8（Security Misconfiguration）で整理されています。脆弱とみなす条件の一つに、HTTPメソッドやログ機能などの不要な機能が有効になっていることが挙がっています。悪用の容易さはEasy、広がりはWidespreadという評価です。

もう一つの論点は把握漏れです。API9（Improper Inventory Management）は、APIのホストの目的や環境、動いている版が不明なこと、ホストの一覧が無いか古いことを脆弱な状態として挙げています。アプリ用のAPIとオンラインストアを別々の時期に作った会員基盤では、どのサーバーで何が動いているかの一覧が古くなりやすいものです。10項目の全体はOWASP API Security Top 10 2023の全10項目で解説しています。

外に開いた管理機能を見つける｜公開パスを確かめるスクリプトと設定

標準ライブラリで動く公開機能チェックスクリプトと検証用サーバーでの結果

自社のサーバーで、管理用や診断用の窓口が外から200で応答しないかを確かめるスクリプトです。Python 3の標準ライブラリだけで動きます。対象のパスは代表的なものに絞っているので、自社で使っているフレームワークに合わせて足してください。実行は必ず自社が管理するサーバーに限ります。exposure_check.pyとして保存します。

import sys, uuid, urllib.request, urllib.error

BASE = sys.argv[1].rstrip("/")

PATHS = [
    ("/actuator/env",        "Spring Boot Actuator 環境変数"),
    ("/actuator/heapdump",   "Spring Boot Actuator ヒープダンプ"),
    ("/actuator/mappings",   "Spring Boot Actuator ルート一覧"),
    ("/server-status",       "Apache mod_status"),
    ("/phpinfo.php",         "PHP 設定情報"),
    ("/.env",                "環境変数ファイル"),
    ("/.git/HEAD",           "Gitリポジトリ"),
    ("/swagger-ui/index.html", "API仕様書UI"),
    ("/v3/api-docs",         "OpenAPI定義"),
]

def get(path):
    req = urllib.request.Request(BASE + path, headers={"User-Agent": "exposure-check"})
    try:
        with urllib.request.urlopen(req, timeout=10) as r:
            return r.status, r.read(2048)
    except urllib.error.HTTPError as e:
        return e.code, b""
    except Exception:
        return 0, b""

# 存在しないパスの応答を基準にして、何でも200を返す設定の誤検知を避ける
base_code, base_body = get("/" + uuid.uuid4().hex)

ng = 0
for path, label in PATHS:
    code, body = get(path)
    exposed = code == 200 and not (base_code == 200 and body[:512] == base_body[:512])
    ng += exposed
    print(f"{'NG' if exposed else 'OK'} {code:3} {path:24} {label}")
sys.exit(1 if ng else 0)

2026年10月7日に、手元で立てた検証用サーバーに対して実行した結果です。8765番は管理機能を外に開いた版、8766番はそれらに404を返す版です。

$ python exposure_check.py http://127.0.0.1:8765
NG 200 /actuator/env            Spring Boot Actuator 環境変数
NG 200 /actuator/heapdump       Spring Boot Actuator ヒープダンプ
OK 404 /actuator/mappings       Spring Boot Actuator ルート一覧
OK 404 /server-status           Apache mod_status
OK 404 /phpinfo.php             PHP 設定情報
OK 404 /.env                    環境変数ファイル
OK 404 /.git/HEAD               Gitリポジトリ
OK 404 /swagger-ui/index.html   API仕様書UI
NG 200 /v3/api-docs             OpenAPI定義

$ python exposure_check.py http://127.0.0.1:8766
OK 404 /actuator/env            Spring Boot Actuator 環境変数
OK 404 /actuator/heapdump       Spring Boot Actuator ヒープダンプ
OK 404 /actuator/mappings       Spring Boot Actuator ルート一覧
OK 404 /server-status           Apache mod_status
OK 404 /phpinfo.php             PHP 設定情報
OK 404 /.env                    環境変数ファイル
OK 404 /.git/HEAD               Gitリポジトリ
OK 404 /swagger-ui/index.html   API仕様書UI
OK 404 /v3/api-docs             OpenAPI定義

NGが1つでもあれば終了コード1を返すため、CIに組み込んでデプロイのたびに回せます。どのパスにも200を返す作りのサーバーでは、存在しないパスの応答と中身が同じものを除外して誤検知を避けます。すべてのパスに同じトップページを返す検証用サーバーで試すと、9件とも200でしたが、判定はすべてOKになり終了コードは0でした。

Spring Boot 4.1系で管理機能を閉じる設定と管理用ポートの分離

Spring Bootを使っている場合は、すべての管理機能を閉じたうえで必要なものだけを開ける形にします。次の例は、2026年10月7日時点の公式ドキュメントにある設定項目で組んだapplication.ymlです。起動確認までは本記事で行っていないため、自社の版のドキュメントと突き合わせてから使ってください。

management:
  server:
    port: 9090            # 管理用ポートを分け、外部の負荷分散装置からは転送しない
  endpoints:
    access:
      default: none       # すべて閉じてから必要なものだけ開ける
    web:
      exposure:
        include: health
  endpoint:
    health:
      access: read-only
    env:
      show-values: never

management.endpoints.access.defaultをnoneにすると、個別に許可したもの以外は呼べなくなります。管理用のポートを分けておけば、負荷分散装置で利用者向けのポートだけを外に転送する構成にできます。公式ドキュメントの説明では、heapdumpとshutdownは既定でアクセスが制限されている機能です。それでも設定を明示しておけば、後から誰かが公開範囲を広げたときに差分で気付けます。

構成ソフトウェアの一覧を作り版と公開範囲を突き合わせる棚卸し

スクリプトで外から確かめるのと並行して、サーバーの中で何が動いているかの一覧を作ります。アプリのAPI、オンラインストア、管理画面、バッチの各サーバーについて、使っているフレームワーク、ミドルウェア、その版、外から届くポートを1行ずつ書き出してください。

一覧ができたら、各ソフトウェアの公式ドキュメントで、既定で有効になっている管理機能を確かめてください。ソフトウェアの部品を機械的に書き出す方法はSBOMとは？ソフトウェア部品表の目的・フォーマットと作成・運用の判断で扱っています。設定の不備から情報が見えてしまった別の事例として、生命保険協会の契約照会システム情報漏えいも参考になります。

不正利用の痕跡に気付くためのログ確認｜管理パスへのアクセスを抽出

アクセスログから管理パスへの試行と成功を数えるスクリプトと出力

管理機能を探す攻撃は、よく知られたパスを順に試す形になりやすいものです。Webサーバーのアクセスログ（combined形式）から、管理パスへのリクエストを接続元ごとに数え、200で成功したものを応答の大きさと一緒に出すスクリプトです。scan_log.pyとして保存します。

import re, sys
from collections import defaultdict

PAT = re.compile(r'^(\S+) .*?"(?:GET|POST|HEAD) (/(?:actuator|server-status|phpinfo\.php|\.env|\.git/|v3/api-docs|swagger-ui)\S*) [^"]*" (\d{3}) (\d+|-)')

hits = defaultdict(list)
for line in open(sys.argv[1], encoding="utf-8", errors="replace"):
    m = PAT.match(line)
    if m:
        ip, path, status, size = m.groups()
        hits[ip].append((status, int(size) if size.isdigit() else 0, path))

for ip, rows in sorted(hits.items(), key=lambda kv: -sum(s == "200" for s, _, _ in kv[1])):
    ok = [r for r in rows if r[0] == "200"]
    print(f"{ip}  試行={len(rows)}  成功={len(ok)}  成功時の最大応答={max((b for _, b, _ in ok), default=0):,}バイト")
    for status, size, path in ok:
        print(f"    200 {size:>12,} {path}")

架空のサンプルログ（接続元は文書用に予約されたアドレス）で2026年10月7日に実行した出力です。

$ python scan_log.py access.log
198.51.100.7  試行=4  成功=2  成功時の最大応答=48,211,337バイト
    200        5,321 /actuator/env
    200   48,211,337 /actuator/heapdump
192.0.2.33  試行=2  成功=0  成功時の最大応答=0バイト

1つの接続元が4つの管理パスを試し、そのうち2つが200で成功しています。heapdumpの応答が約48MBと大きいことから、メモリの中身が丸ごと外に出た可能性を疑う手がかりになります。404しか返っていない接続元は、探索はされたものの成功していません。見るべきログの種類と調べ方の全体は不正アクセスのログ確認・解析方法が参考になります。

200が見つかったときの初動と個人情報保護委員会への報告の段取り

管理パスへの成功が見つかったときは、次の順で動きます。

  1. 該当の機能を閉じるか、外部からの経路を遮断する
  2. 成功した接続元と時刻、応答の大きさを記録として残す
  3. 応答に含まれ得た情報（設定値・認証情報・会員データ）を洗い出す
  4. 漏れた可能性のある認証情報を変更し、データベースのアクセス記録を確かめる

会員の個人データが漏えいした恐れがあると分かった段階で、個人情報保護委員会の漏えい等の対応に沿った報告が必要になるか判断します。報告の対象と期限は個人情報保護委員会への報告義務で整理しているので、報告の要否を判断する際に確認してください。ミスターマックスも、同委員会への報告と警察への相談を公表しています。

自社サーバーの公開機能を今すぐ点検すべき事業者と後回しでよい事業者

フレームワークやパッケージでアプリとECを自社運用している事業者の対応

アプリのAPIやECサイトを、フレームワークやECパッケージを使って自社のサーバーで運用しているなら、exposure_check.pyに相当する点検を今週中に回してください。本番だけでなく、検証用や旧版のAPIのサーバーも対象です。API9が挙げるとおり、忘れられたホストほど設定が古いまま残ります。

アプリとオンラインストアを別々の時期に作り、後から会員情報をつないだ構成は、とくに優先度が高いと考えます。サーバーごとに作った会社や担当者が違い、管理機能の設定が統一されていないことがあるためです。点検は、構成ソフトウェアの一覧を作ってから、外からのスクリプトとログ確認を一つずつ当てる順で進めます。

SaaS型のECやアプリ基盤に任せている事業者で過剰になる場面

サーバーの運用をSaaS型のECやアプリ基盤に任せていて、自社でサーバーを持っていない場合、自前でサーバーの公開パスを調べる作業は過剰です。サーバーを構成するソフトウェアの管理は提供事業者の責任範囲だからです。その場合は、管理画面のアカウントと権限、外部アプリや連携サービスに渡している権限を見直せば足ります。

判断に迷うのは、どのサーバーで何が動き、何が外から届くかを社内で把握できていない場合です。サーバーの公開範囲や設定を第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、外から呼べる管理機能の有無を含めて点検できます。

よくある質問

ミスターマックスの不正アクセスについて、会員とサーバーを運営する担当者から出やすい質問をまとめました。

MrMaxアプリやオンラインストアの会員は全員が対象ですか？

公表では、2026年10月3日時点で会員登録している人が対象で、人数は最大1,735,154人です。ただし、流出した項目は登録状況によって異なるというのが、公表されている説明です。対象者には同社からお詫びのメールが個別に届くため、そのメールの有無で確かめられます。問い合わせは、お知らせに記載された専用の窓口で受け付けています。

パスワードやクレジットカード情報は漏れていますか？

同社は、パスワードとクレジットカード情報は流出していないと確認したと説明しています。住所、生年月日、購入履歴も流出していません。流出したのは会員ID、氏名、メールアドレス、電話番号です。ただし、同じメールアドレスとパスワードを他のサービスで使っている場合は、念のためそちらを変えておくと安心です。

不正アクセスの原因やソフトウェアの名前は公表されていますか？

公表されていません。お知らせは、第三者が本サービスを構成するソフトウェアの機能を不正に利用してサーバーに侵入したとだけ書いています。ソフトウェアの名前、使われた機能、脆弱性かどうかは明らかにされていません。外部の専門機関と調査を進めており、新たな事実が分かれば知らせるとしています。

ミスターマックスを名乗るSMSや電話が来たらどうすればよいですか？

同社はパスワードやクレジットカード番号を尋ねることはないとしています。SMSや電話でそれらを求められたら、応じずに切ってください。SMSのリンクは開かず、確かめたいことがあれば公式サイトから入り直します。電話番号と氏名がそろって流出しているため、名前を呼ばれても本物とは限りません。

自社のサーバーで同じことが起きないか、何から確かめればよいですか？

最初に、アプリのAPI、オンラインストア、管理画面などのサーバーで動いているソフトウェアと版の一覧を作ります。次に、本記事のexposure_check.pyで、管理用や診断用のパスが外から200で応答しないかを確かめてください。最後に、アクセスログから管理パスへの試行と成功を数えられる状態にします。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.06　テックブログ 大和証券の不正アクセスと約11万人分の口座番号：問い合わせ管理の委託先に残さない設計
  2. 2026.10.06　テックブログ 焼肉きんぐの不正アクセスと1,078万件の会員情報｜全件規模の流出を防ぐAPIとログの点検
  3. 2026.10.06　テックブログ 原子力研究開発機構の不正アクセスと身分証画像の漏えい｜研究支援サイトのファイル保管を点検する手順
  4. 2026.03.31　コラム 配偶者特別控除の早見表【2026年・令和8年分】満額38万円は年収169万円まで
  5. 2026.10.01　テックブログ AWS VPN Clientの使い方：6.x系のインストールとCLI・接続できない時の確認先

RELATED POSTS 関連記事

一覧へ戻る

目次