スノーピークは2026年11月13日、リユース買取サービス、イベント予約システム、コミュニティアプリの3つで脆弱性を突かれた不正アクセスがあり、公式オンラインストアと公式会員アプリでは外部で取得されたとみられるIDとパスワードによる不正ログインが最大445件あったと公表しました。この記事では、4系統それぞれの対象者数と項目、利用者が警戒すべき連絡を整理します。後半は、本体のECサイトの外側に買取・予約・コミュニティのような周辺サービスを抱える企業の開発者向けに、サービスを台帳にして脆弱性診断の順番を決める方法と、不正ログインで閲覧される情報を減らすマイページの設計を、実行できるPythonのコード付きで解説します。
まとめ：スノーピークの4系統の不正アクセスと、周辺サービスを持つ企業が見直す診断範囲
今回の公表は、性質の異なる2つの型に分かれます。リユース買取（24,948名・調査継続中）、イベント予約（5,923名分）、コミュニティアプリ（21,553名）の3つは、各サービスの脆弱性が原因です。オンラインストアと会員アプリの最大445件は、他所で漏れたIDとパスワードを使った不正ログインで、同社のシステムからのパスワード流出はないとしています。
買取サービスの利用者は、振込先の口座情報と生年月日が対象に入っています。スノーピークや金融機関を名乗るメール・SMS・電話・郵便物に注意してください。
開発者が自社に持ち帰る論点は、本体ECではなく周辺のサービスです。優先度の高い順に並べると次の4つになります。
- 部署や委託先ごとに立ち上げた外部公開サービスを1枚の台帳にまとめる
- 口座・生年月日などを持ち、診断を受けていないサービスから脆弱性診断を入れる
- 不正ログインされても読まれる情報が少ないよう、マイページの表示を再認証で絞る
- 漏えい時の報告期限と、利用者への注意喚起の文面を先に用意する
1つ目が無いと、2つ目以降の範囲を決められません。
11月13日の公表で確定した4系統・約5.2万名分の内訳と、原因が分かれる2つの型
リユース買取・イベント予約・コミュニティの3件は各サービスの脆弱性が原因
スノーピークの11月13日の公表によると、3つのサービスはいずれも「当該サービスの脆弱性」を突かれています。日付と件数は次のとおりです。
| サービス | 不正アクセス日 | 確認日 | 対象 |
|---|---|---|---|
| リユース買取 | 11月9日 | 11月12日 | 24,948名（調査継続中） |
| イベント予約 | 10月30日、11月8日〜9日 | 11月11日 | 5,923名分 |
| コミュニティアプリ | 10月30日、11月8日〜9日 | 11月10日 | 21,553名 |
3つを足すと52,424名分ですが、同じ人が複数のサービスを使っていれば重なります。イベント予約とコミュニティアプリは不正アクセスの日付が同じです。ただし、同じ攻撃者によるものか、脆弱性の種類は何か、各サービスを自社と委託先のどちらが運営していたかは書かれていません。項目の重さはサービスで大きく違います。買取サービスは氏名・住所・生年月日・職業に加え、振込先の銀行名・支店名・口座種別・口座番号・口座名義まで含みます。イベント予約は申込者の連絡先と生年月日のほか、同伴者の氏名・年齢・性別、宿泊先や車種などの申込内容が対象です。コミュニティアプリは会員番号、表示名、自己紹介文、カバー画像で、住所やメールアドレスは含まれません。
オンラインストアと会員アプリは外部で得た認証情報による最大445件
4つ目は脆弱性ではありません。第三者が外部で取得したとみられるIDとパスワードで一部の会員アカウントにログインした、いわゆるリスト型攻撃です。11月9日に検知し、不正ログインの期間は10月29日〜30日と11月9日、件数は最大445件とされています。
閲覧された可能性があるのは、氏名、住所、電話番号、メールアドレス、生年月日、購入履歴、保有ポイント、支払い方法、届け先等です。カード番号の全桁は表示されない一方、先頭6桁と末尾2桁が表示される画面が見られた可能性があるとしています。ログインされたアカウントで画面に出る情報が、そのまま被害の範囲になった形です。
4サービスの一時停止とストアの11月13日再開、委員会への報告
同社は4つのサービスを一時停止し、公式オンラインストアは11月13日中に再開しました。ほかのサービスはセキュリティを強化したうえで順次再開する予定です。個人情報保護委員会など関係機関へ報告中で、外部の専門家と影響範囲の特定と原因の調査を進めています。ログイン時の認証も強化したとしています。現時点で本件に起因する二次被害は確認されていません。
振込先口座と同伴者・カード番号の一部、利用者が警戒する連絡と確かめ方
リユース買取の口座情報と生年月日で想定される、金融機関を装う連絡
口座の暗証番号やネットバンキングのログイン情報は含まれていません。口座番号と名義だけで預金を引き出すことはできません。それでも、銀行名と支店名、口座番号、生年月日、住所がそろうと、「お取引口座の確認です」と銀行を名乗る電話やSMSが本物らしく聞こえます。本人しか知らないはずの情報を先に示されると、暗証番号やワンタイムパスワードを答えてしまう流れが生まれやすくなります。
公表文も、同社や金融機関を装った不審なメール、SMS、電話、郵便物に注意し、添付ファイルやURLを開かずに破棄するよう呼びかけています。同社がパスワード、カード番号、口座の暗証番号を尋ねることはありません。
ユーザーサービス係の相談窓口とパスワードの使い回しをやめる作業
利用者がやることは多くありません。
- スノーピークで使っていたパスワードを他のサービスでも使っているなら、そちらを先に変える
- スノーピークや銀行を名乗る連絡が来たら、その場で答えず、自分で調べた番号から問い合わせる（スノーピーク ユーザーサービス係 0120-010-660、平日9時〜17時）
- イベントに家族や知人を同伴者として登録していた場合は、本人にも事情を伝えておく
不正ログインの445件は、他所で漏れたパスワードが使われた可能性が高い被害です。スノーピーク側でパスワードを変えるだけでは、同じ組み合わせを使う別のサービスが残ります。リユース業界の別の事案での本物の通知メールの見分け方は、ブックオフ不正アクセスと本物メールの見分け方で整理しています。
本体ECの外側にある買取・予約・コミュニティを台帳にして診断の順番を決める方法
委託やSaaSで動く周辺サービスが、脆弱性診断の計画から外れる事情
今回の4系統のうち、脆弱性が原因だったのは本体のオンラインストアではなく、買取・イベント予約・コミュニティという周辺の3サービスでした。運営主体は公表されていませんが、一般に周辺サービスは本体ECと事情が違います。事業部ごとに立ち上がり、開発や運用を別の委託先やSaaSに任せ、別ドメインやサブドメインで動くことが多いのです。年1回の脆弱性診断を本体ECにだけ発注していると、こうしたサービスは「誰も診断を発注していない」状態のまま残ります。
持っている情報が軽いとも限りません。買取サービスは本人確認と振込のために、本体ECより重い口座情報を持ちます。イベント予約は申込者以外の同伴者の情報まで集めます。
IPAと経済産業省が2023年3月に公開したガイドラインのプレス発表では、被害を受けたECサイト運営事業者20社のヒアリングで、75%が構築プログラムやCMS等の脆弱性を放置するか更新を怠っており、90%が保守など運用時のセキュリティ対策を実施していなかったと報告されています。1社あたりの平均漏えい件数は約3,800件、事故対応費用の平均は約2,400万円でした。
保有項目・最終診断日・委託の有無で点数を付けるPythonの台帳
まず、外部に公開しているサービスを1枚の表に集めます。列は、サービス名、主管部署、運営主体、ログイン方式、保有する個人情報の項目、最終診断日の6つで十分です。次のコードは、その表をcsvモジュールで読み、漏れたときの重さ、診断からの経過、委託かどうか、メールアドレスでログインできるかを点数にして、診断の順番を出します。
# 本体ECの周辺にある外部公開サービスを台帳にし、脆弱性診断の優先順位を付ける（Python 3.9以上・標準ライブラリのみ）
import csv
import io
from datetime import date
TODAY = date(2026, 11, 14)
# 説明用のダミー台帳。実際は各部署・委託先への聞き取りとDNSの登録内容から作る
INVENTORY = """service,owner,operator,login,items,last_diagnosed
公式オンラインストア,EC部,自社,email,氏名;住所;電話;購入履歴;カード一部,2026-04-10
会員アプリ,EC部,委託A,email,氏名;住所;電話;保有ポイント,2025-09-01
リユース買取,リユース事業部,委託B,email,氏名;住所;生年月日;口座,
イベント予約,イベント事業部,SaaS-C,email,氏名;住所;生年月日;同伴者,
コミュニティアプリ,広報部,委託D,email,表示名;自己紹介,2024-06-20
キャンペーン応募,広報部,委託E,none,氏名;メール,
"""
# 漏れたときの重さ。口座と生年月日は金融機関を装う連絡の材料になるため重くする
WEIGHT = {"口座": 5, "カード一部": 4, "生年月日": 3, "住所": 3, "電話": 2, "同伴者": 2,
"氏名": 1, "メール": 1, "購入履歴": 1, "保有ポイント": 1, "表示名": 1, "自己紹介": 1}
def score(row):
items = row["items"].split(";")
data = sum(WEIGHT.get(i, 1) for i in items)
if not row["last_diagnosed"]:
age, gap = "未診断", 10
else:
days = (TODAY - date.fromisoformat(row["last_diagnosed"])).days
age, gap = f"{days}日前", 0 if days <= 365 else 5
outsourced = 3 if row["operator"] != "自社" else 0 # 委託・SaaSは自社の診断計画から漏れやすい
login = 2 if row["login"] == "email" else 0 # メールアドレスでログインできるとリスト型攻撃の的になる
return data + gap + outsourced + login, age
rows = list(csv.DictReader(io.StringIO(INVENTORY)))
ranked = sorted(((score(r), r) for r in rows), key=lambda x: -x[0][0])
for (total, age), r in ranked:
print(f"{total:>3} {r['service']}（{r['operator']}・最終診断 {age}）")Python 3.14.10（Windows）で2026年11月14日に実行した結果です。台帳の値は説明用に作ったもので、スノーピークのサービス構成やデータを再現したものではありません。
27 リユース買取（委託B・最終診断 未診断）
24 イベント予約（SaaS-C・最終診断 未診断）
17 会員アプリ（委託A・最終診断 439日前）
15 キャンペーン応募（委託E・最終診断 未診断）
13 公式オンラインストア（自社・最終診断 218日前）
12 コミュニティアプリ（委託D・最終診断 877日前）実行結果の読み方と、IPAガイドラインが求める公開前・定期・改修時の診断
本体のオンラインストアは5番目に下がりました。半年前に診断を受けているからです。上に来たのは、口座や生年月日を持ち、一度も診断を受けていない委託先とSaaSのサービスでした。重みと加点の値は説明用です。自社で使うときは、項目の重さを情報セキュリティの規程に合わせて決め、点数の上位から診断の見積を取ります。
診断の時期は、ECサイト構築・運用セキュリティガイドラインが目安になります。プレス発表によると、構築時の必須要件として公開前の脆弱性診断、運用時の必須要件として定期的な診断とカスタマイズを行った際の診断を挙げています。ガイドラインは中小企業のECサイトを主な対象としていますが、想定読者には外部委託先事業者やSaaS型サービスを使う担当者も含まれるという説明です。会員登録と個人情報の入力がある周辺サービスにも、同じ3つの時期を当てはめてかまいません。
委託先やSaaSのサービスは、自社で診断を発注できるとは限りません。その場合は、契約の更新時に「年1回の第三者診断と結果の共有」を条件に入れるか、SaaS事業者が公開する診断の実施状況を確かめます。どちらもできないサービスに、口座や生年月日を預ける設計は避けます。
不正ログイン後に閲覧される画面を減らす、マイページの表示と再認証の設計
カード番号の一部や住所が表示されるマイページが、被害の範囲を決める理由
リスト型攻撃を完全に止める手段はありません。ログインを許したとき、画面に何が出るかで被害の範囲が決まります。今回のオンラインストアでは、氏名や住所に加え、生年月日、購入履歴、カード番号の先頭6桁と末尾2桁が表示される画面が閲覧の対象になりました。正しいIDとパスワードでのログインに見える以上、ログインの直後から全項目が見える設計では、445件それぞれで全項目が読まれた前提で報告と連絡をすることになります。
住所や生年月日を変更したい利用者は一部です。注文の確認や保有ポイントの確認で開いたマイページに、毎回すべての個人情報を出す必要はありません。
再認証の前は住所や生年月日を伏せて表示するPythonの関数
次のコードは、ログインしただけの状態では住所を都道府県まで、電話番号を末尾4桁まで、生年月日を非表示にし、直近10分以内にパスワードの再入力やワンタイムコードで再認証した場合だけ全項目を返す表示関数です。カードはブランドと末尾4桁に限ります。
# 会員のマイページに出す項目を、再認証の有無で絞る表示関数（Python 3.9以上・標準ライブラリのみ）
from datetime import datetime, timedelta
REAUTH_WINDOW = timedelta(minutes=10) # 直近の再認証（パスワード再入力やワンタイムコード）から有効な時間
def mask_card(number, brand):
# 先頭の桁は出さず、ブランドと末尾4桁だけにする
return f"{brand} 末尾{number[-4:]}"
def account_view(member, last_reauth, now):
fresh = last_reauth is not None and now - last_reauth <= REAUTH_WINDOW
view = {
"氏名": member["name"],
"カード": mask_card(member["card"], member["brand"]),
"保有ポイント": member["points"],
}
if fresh:
view.update(住所=member["address"], 電話=member["phone"], 生年月日=member["birth"])
else:
view.update(住所=member["address"][:3] + "（再認証で表示）",
電話="***-****-" + member["phone"][-4:],
生年月日="（再認証で表示）")
return view
member = {"name": "会員A", "card": "4111111111111111", "brand": "VISA", "points": 1200,
"address": "新潟県（ダミー）", "phone": "000-0000-1234", "birth": "1990-01-01"}
now = datetime(2026, 11, 14, 12, 0)
print("ログイン直後:", account_view(member, None, now))
print("再認証5分後:", account_view(member, now - timedelta(minutes=5), now))同じ環境で実行した結果です。カード番号はテスト用の値です。
ログイン直後: {'氏名': '会員A', 'カード': 'VISA 末尾1111', '保有ポイント': 1200, '住所': '新潟県（再認証で表示）', '電話': '***-****-1234', '生年月日': '（再認証で表示）'}
再認証5分後: {'氏名': '会員A', 'カード': 'VISA 末尾1111', '保有ポイント': 1200, '住所': '新潟県（ダミー）', '電話': '000-0000-1234', '生年月日': '1990-01-01'}伏せるのは画面だけでは足りません。マイページが呼ぶAPIの応答に全項目が入っていれば、ブラウザの開発者ツールで読めます。サーバー側の応答そのものを絞ってください。APIの段階での認可とトークン失効の組み方はAPI不正アクセス対策の実装手順で解説しています。
OWASPが挙げる多要素認証と、メールアドレスをログインIDにしない設計
入口の対策は、OWASPのCredential Stuffing Prevention Cheat Sheetが整理しています。最も有効とされるのは多要素認証で、Microsoftの分析ではアカウント侵害の99.9%を防げた可能性があると紹介されています。新しい端末や見慣れない接続元からのログインに限って求める方法も、同資料が挙げる対策の一つです。
同じ資料は、IPアドレスによる遮断を単独や主要な防御にしないよう求めています。メールアドレスをログインIDにすると漏えいリストとの照合が成立しやすいという点も、同資料の指摘です。会員数が多いサービスでIDの形式を変えるのは負担が大きいので、まずは多要素認証と、パスワードは正しいのに2要素目で失敗したときの利用者への通知から入れます。失敗ログインの集計による検知と漏えいパスワードの照合は、パスワードリスト攻撃の検知の指標と実装でコード付きで解説しました。
判断：周辺サービスを全部同じ深さで診断しない線引きと、報告の期限
口座や生年月日を持つ未診断のサービスから診断し、表示名だけの場は後回し
周辺サービスをすべて本体ECと同じ深さで毎年診断するのは、多くの企業で予算が合いません。線を引きます。口座、生年月日、本人確認の情報、カード番号の一部のいずれかを持ち、過去1年に診断を受けていないサービスは、次の改修を待たずに診断します。表示名と自己紹介文だけを持つコミュニティのような場は、ログイン方式と管理画面の公開範囲の確認から始め、本格的な診断は次の改修時に回してかまいません。
逆に、台帳を作らずに本体ECの診断の範囲だけを広げる方法は採りません。どのサービスがあるかを知らないまま範囲を決めても、今回のような周辺の3サービスは見つからないからです。台帳は、新しいキャンペーンや予約サイトを立ち上げるたびに主管部署が行を足す運用にします。
1,000人超・不正目的のおそれに当たる漏えいの速報3〜5日と確報60日
個人情報保護委員会は、報告が必要な事態として4つの類型を示しています。不正の目的によるおそれがある漏えい、財産的被害のおそれがある漏えい、本人の数が1,000人を超える漏えい、要配慮個人情報の漏えいです。外部からの不正アクセスで1,000人を超える会員の情報に影響が出たおそれがある場合は、少なくとも不正の目的によるおそれと1,000人超の2つに当たります。
速報は発覚から3〜5日以内が目安で、確報は30日以内、不正の目的によるおそれがある場合は60日以内とされています。報告の流れは個人情報保護委員会への報告義務の実務で解説しました。周辺サービスの棚卸しと、どこから診断を入れるかを第三者と一緒に決めたい場合は、脆弱性診断・セキュリティ診断で相談できます。
よくある質問
スノーピークの不正アクセスについて、利用者と開発者から出やすい質問をまとめました。2026年11月14日時点の公表内容にもとづきます。
スノーピークの不正アクセスで流出した可能性があるのはどんな情報ですか？
サービスで異なります。リユース買取は氏名、住所、生年月日、電話番号、メールアドレス、注文情報、振込先の口座情報など（24,948名）、イベント予約は申込者の連絡先と生年月日、同伴者の氏名・年齢・性別、申込内容（5,923名分）、コミュニティアプリは会員番号、表示名、自己紹介文、カバー画像（21,553名）です。オンラインストアと会員アプリでは最大445件で、住所や購入履歴、カード番号の一部が閲覧された可能性があります。
口座情報が流出すると預金を引き出されますか？
公表によると、口座の暗証番号とネットバンキングのログイン情報は含まれていません。口座番号と名義だけでは預金は引き出せません。注意すべきなのは、口座や生年月日を知っていることを示して信用させ、暗証番号やワンタイムパスワードを聞き出す連絡です。スノーピークも金融機関も、電話やメールで暗証番号を尋ねることはありません。
スノーピークのパスワードは流出しましたか？
同社は、当社システムからのパスワード流出はないとしています。オンラインストアと会員アプリの不正ログインは、外部で取得されたとみられるIDとパスワードが使われたものです。同じパスワードを他のサービスでも使っている場合は、そちらのパスワードを先に変えてください。
スノーピークのオンラインストアは今使えますか？
4つのサービスはいったん停止され、公式オンラインストアは11月13日中に再開しました。リユース買取、イベント予約、コミュニティアプリは、セキュリティを強化したうえで順次再開する予定とされています。再開日は2026年11月14日時点で公表されていません。ログイン時の認証は強化されています。
自社の周辺サービスはどこまで脆弱性診断すればよいですか？
まず外部公開しているサービスを部署と委託先に聞き取って台帳にします。そのうえで、口座・生年月日・本人確認の情報などを持ち、過去1年に診断を受けていないものから順に診断します。時期の目安は、IPAのECサイト構築・運用セキュリティガイドラインにある公開前・定期・改修時の3つです。表示名だけを扱う場は、ログイン方式と管理画面の公開範囲の確認から始めます。
関連記事
- パスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装：オンラインストアの不正ログインと同じ手口の検知と対策
- API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：会員アプリとAPIの段階での認可
- ブックオフ不正アクセス：約638万人の対象確認と本物メールの見分け方：リユース事業での不正アクセスと利用者への通知
- 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：不正アクセスで漏えいしたときの報告の流れ
