--- title: "ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検" url: "https://www.issoh.co.jp/tech/details/18387/" published: 2026-10-16 updated: 2026-10-16 categories: ["セキュリティ"] publisher: "株式会社一創" --- # ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検 ソースネクストは2026年10月15日、会員情報を管理するシステムが第三者から不正アクセスを受け、会員の個人情報が外部に流出したと公表しました。流出した可能性があるのは22,519,960件で、メールアドレスとパスワードを含む13項目です。本記事では、まず会員の側が知りたい「急にログインできない理由」「パスワード再設定」「自分が対象か」「どこに問い合わせるか」に公式発表の文言で答えます。後半では、会員情報を返すAPIを運営する側が、返却項目と大量取得の検知をどう点検するかを、手元で動かしたPythonとSQLで示します。 ## まとめ：ソースネクスト不正アクセスで公表された事実と会員が今日やること 確定しているのは次の事実です。2026年10月9日（金）10時頃から第三者による不正アクセスがあり、会員情報取得APIが不正に利用されて会員の情報が取得されました。同社が不正アクセスを確認したのは10月13日（火）9時頃で、同日13時36分までに封じ込めを完了しています。クレジットカード情報は対象のシステムに保存されておらず、流出の対象外です。 会員がやることは2つです。ソースネクストのパスワードを再設定すること。同じメールアドレスとパスワードの組み合わせを使っている他のサービスのパスワードを変えること。同社は全会員のパスワードをすでに変更済みで、従来のパスワードではログインできません。運営側が学べるのは、会員情報を返すAPIが4日間にわたって使われ続けた点です。返す項目と、1つの認証情報が見る会員の数を確かめてください。 | 項目 | 公表されている内容 | | --------- | ------------------------- | | 不正アクセスの開始 | 2026年10月9日（金）10時頃 | | 確認と封じ込め | 10月13日9時頃確認・13時36分封じ込め完了 | | 経路 | 会員情報取得APIの不正利用 | | 対象件数 | 22,519,960件（流出した可能性） | | パスワード | 対象項目に含む・全会員分を変更済み | | カード情報 | 対象システムに保存なし・対象外 | | 専用窓口 | 0120-035-116（毎日10時〜18時受付） | ## 会員が最初に確かめる4点｜ログインできない理由・再設定・対象範囲・専用窓口 ### 急にログインできないのは全会員のパスワードを初期化した措置のため 公式FAQは「急にログインできなくなった」という質問に「はい」と答え、第三者による不正利用を防ぐため、順次パスワードのリセット（初期化）を実施していると説明しています。10月16日の追記では、すべての会員のパスワードがすでに変更済みで、従来のパスワードは使えない状態だと明記しました。 ログインするとパスワードの再設定を求める画面が出るので、案内に従って新しいパスワードを決めます。同じ追記によると、再設定サイトにアクセスが集中してつながりにくくなっています。従来のパスワードはもう使えないため、急いで何度も試す必要はありません。時間をおいてから再設定してください。 ### 2026年10月13日13時36分までに登録した会員が対象で全項目とは限らない 公式FAQによると、対象の範囲は「2026年10月13日13時36分までに当社にご登録があるお客様」です。封じ込めの完了時刻までに登録していた会員が対象になるという書き方で、長く使っていないアカウントも外れるとは書かれていません。ただし13項目すべてが全員分流出したわけではなく、登録状況によって対象の項目は異なります。 対象の会員には10月15日以降、登録メールアドレスへ順次お詫びと案内のメールが届きます。メールアドレスを登録していない会員には、書面の郵送で連絡する予定とされています。迷惑メールのフォルダも確認してください。 ### 同じメールアドレスとパスワードを使う他サービスの変更優先順位 公式発表は、流出した可能性のあるメールアドレスとパスワードの組み合わせで、第三者が他のサービスへのログインを試みるおそれがあるとしています。同じ組み合わせを使っているサービスがあれば、そちらのパスワードも変えるよう求めています。順番は、メールアカウント、ネット銀行と決済、通販サイトの順が目安です。メールを乗っ取られると、他のサービスのパスワード再設定まで奪われるからです。 使い回しを避けるパスワードの決め方は[パスワード管理のベストプラクティス](https://www.issoh.co.jp/column/details/13508/)で整理しています。手元のパスワードが既知の漏えいに含まれるかを確かめる手順は、同じ月に公表された[銀のさらの不正アクセスの記事](https://www.issoh.co.jp/tech/details/18365/)でPythonの実行例とともに解説しました。 ### お詫びメールと偽メールの見分け方と専用窓口0120-035-116の受付時間 同社名のお詫びメールが届くこと自体は不自然ではありません。一方で公式発表は、同社や関係先を装ったメール、SMS、電話、郵便物が届く可能性にも触れています。身に覚えのないメールやSMSのURL、添付ファイルは開かないこと、不審なサイトに個人情報やパスワードを入力しないことを呼びかけています。 迷ったら、メールのリンクではなく自分でブラウザからソースネクストのサイトを開くか、専用窓口に電話してください。[公式発表（2026年10月15日）](https://www.sourcenext.com/support/i/2026/1015%5Finfo/)に載っている専用窓口は0120-035-116（フリーダイヤル）で、受付は10時〜18時、土日祝日も受け付けています。問い合わせフォームと[よくあるご質問](https://www.sourcenext.com/support/i/2026/1015%5F1/)も同じページから開けます。 ## 公式発表を時系列で確認する｜10月9日10時の不正利用開始から15日の公表まで ### 4日間気付かれなかった会員情報取得APIの不正利用と13日の封じ込め 公式発表の経緯を時刻順に並べると次のとおりです。発表は「その後の調査により」10月9日からの不正アクセスが判明したと書いており、13日の確認時点では開始日は分かっていませんでした。 | 日時 | 出来事 | | --------------- | ------------------------ | | 10月9日（金）10時頃 | 第三者の不正アクセス開始（後日調査で判明） | | 10月13日（火）9時頃 | 会員情報を管理するシステムへの不正アクセスを確認 | | 10月13日（火）13時36分 | 不正な通信の遮断などで封じ込めを完了 | | 10月15日（木） | 公表・個人情報保護委員会への報告 | | 10月16日（金） | 所轄署への被害申告予定・再設定サイト混雑を追記 | 開始から確認までは約95時間です。その間、会員情報取得APIは攻撃者の要求に応え続けたことになります。公式FAQは、原因となったシステムの脆弱性を発覚後直ちに修正したと説明していますが、脆弱性の中身は公表されていません。本記事も手口を断定しません。 ### 個人情報保護委員会への15日の報告と16日の警察への被害申告予定 同社は10月15日（木）に個人情報保護委員会への報告を完了し、16日（金）に所轄警察署へ被害申告を行う予定だとしています。公式発表は外部の専門調査機関と連携して調査を進めるとし、公式FAQは外部の独立したセキュリティ専門機関による第三者調査の準備を進めていると書いています。原因と影響範囲の確定はその結果を待つ段階です。 不正アクセスによる漏えいは報告の対象で、[個人情報保護委員会の「漏えい等の対応とお役立ち資料」](https://www.ppc.go.jp/personalinfo/legal/leakAction/)に報告の様式と記載例があります。民間事業者が速報と確報を出す段取りは[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で整理しました。 ### 2023年2月のオンラインショップ事案との違いはパスワードと公表までの日数 同社は[2023年2月14日](https://www.sourcenext.com/support/i/2023/0214%5Finfo/)にも、オンラインショップへの不正アクセスを公表しています。このときはペイメントアプリケーションの改ざんで、クレジットカード情報112,132件を含む個人情報120,982件が漏えいした可能性があるとされ、メールアドレスについては「パスワードの漏えいはありません」と明記されていました。 今回はその逆で、カード情報は対象外、パスワードは対象項目に入っています。公表までの日数も違います。2023年はカード会社からの連絡（1月4日）から公表まで41日、今回は確認から公表まで2日でした。 ## 2,252万件で流出の可能性がある13項目｜パスワードと会社名・役職が並ぶ意味 ### パスワードの保存形式は未公表で平文かハッシュかを断定できない理由 公式発表が挙げた項目は、メールアドレス、パスワード、氏名、氏名カナ、住所、性別、電話番号、FAX番号、生年月日、会社名、役職名、部署名、システム固有の識別情報（加入サービス・登録日・ログイン日等）の13項目です。パスワードがどの形式で保存されていたかは、公式発表にもFAQにも書かれていません。平文だったのか、ハッシュ化されていたのかは、公表された事実からは判断できません。 形式が分からない以上、会員の側は「読まれた」前提で動くのが安全です。運営側にとっては、ハッシュ化していても流出時に全件リセットが必要になる点は同じです。[OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)はArgon2idをメモリ19MiB・反復2・並列度1以上で使うよう勧めており、解読にかかる時間を延ばして、利用者がパスワードを変えるまでの猶予を作れます。ハッシュと暗号化の違いは[ハッシュ化とは](https://www.issoh.co.jp/column/details/13487/)で解説しています。 ### 会社名・部署名・役職名の流出で増える取引先を装った業務宛てメール 今回の対象項目には、会社名、部署名、役職名も含まれている点に注意が必要です。法人の担当者として製品を登録した会員は、勤務先の情報まで対象に入り得ます。これがそろうと、購入した製品名や役職を書き込んだ、取引先や販売店を装う業務宛てメールが作りやすくなります。加入サービスと登録日も識別情報に含まれるため、「ご利用中の製品の更新手続き」を装う文面は特に疑ってください。 フィッシングが成立する仕組みと実装者向けの対策は[フィッシング詐欺とは](https://www.issoh.co.jp/tech/details/13548/)で解説しています。手口の最新の報告は[フィッシング対策協議会](https://www.antiphishing.jp/)が公開しています。 ## 会員情報取得APIで返す項目を絞る｜パスワード列を応答に入れない許可リスト検査 ### OWASP API3:2023が勧める全項目返却の廃止と返す項目の選び出し 会員情報取得APIの応答にパスワードが含まれていたのか、別の経路で取られたのかは公表されていません。ただ、会員情報を返すAPIが会員テーブルの全列をそのまま返す作りになっていると、パスワードのハッシュや社内用の項目まで外に出ます。 [OWASP API Security Top 10 2023のAPI3（Broken Object Property Level Authorization）](https://api-security.owasp.org/editions/2023/en/0xa3-broken-object-property-level-authorization/)は、APIがオブジェクトの全プロパティを返しがちだと指摘し、to\_json()のような汎用の変換を避けて返す項目を1つずつ選ぶこと、スキーマに基づく応答の検証を追加の層として入れることを求めています。会員APIでは、画面で使う項目だけを許可リストに書き、それ以外は返さない作りが出発点です。 ### 応答JSONからパスワード系と許可外の項目を見つけるPythonスクリプト 次のスクリプトは、APIの応答をJSONファイルとして受け取り、名前にpasswordやhashなどを含む項目と、許可リストにない最上位の項目を一覧にします。Python 3の標準ライブラリだけで動き、check\_response\_fields.pyとして保存します。ALLOWEDは自社の画面で使う項目に書き換えてください。 ``` import json, sys # 会員情報取得APIが返してよい項目（許可リスト） ALLOWED = {"member_id", "name", "email", "services", "last_login"} # 名前にこの語を含む項目は、値の形式によらず返却を禁止する DENY_WORDS = ("password", "passwd", "pwd", "hash", "salt", "secret", "token") def walk(obj, path=""): if isinstance(obj, dict): for k, v in obj.items(): p = f"{path}.{k}" if path else k yield p, k yield from walk(v, p) elif isinstance(obj, list): for i, v in enumerate(obj): yield from walk(v, f"{path}[{i}]") body = json.load(open(sys.argv[1], encoding="utf-8")) errors = [] for p, k in walk(body): low = k.lower() if any(w in low for w in DENY_WORDS): errors.append(f"DENY {p}") elif "." not in p and "[" not in p and k not in ALLOWED: errors.append(f"EXTRA {p}") for e in errors: print(e) print("NG" if errors else "OK", f"{len(errors)}件") sys.exit(1 if errors else 0) ``` 2026年10月16日に、架空の会員1人分の応答2種類で実行しました。1つ目は会員テーブルの列をそのまま返した応答、2つ目は許可リストどおりの応答です。 ``` $ python check_response_fields.py resp_ng.json DENY password_hash EXTRA birthday EXTRA company EXTRA fax NG 4件 $ python check_response_fields.py resp_ok.json OK 0件 ``` 1つ目では、パスワードのハッシュに加えて、画面で使っていない生年月日、会社名、FAX番号が検出されました。終了コードは1なので、CIのテストに組み込めば、応答に項目が増えた変更をマージ前に止められます。 ### 本番相当のデータで会員APIの全エンドポイントに毎回かける運用 このスクリプトは、テスト用の会員データを入れた検証環境で、会員情報を返すエンドポイントすべての応答に対して回します。項目が増える変更は、列の追加やORMの設定変更など、APIのコードに触れずに起きることが多いからです。許可リストを広げるときはプルリクエストで理由を書き、レビューを通す運用にしてください。名前で判定するため、pwのような短い列名は検出できません。自社の命名に合わせてDENY\_WORDSを足してください。 ## 大量取得を1時間単位で検知する｜認証情報ごとの参照会員数を数えるSQL ### 毎秒約66件の取得はリクエスト数の上限だけでは止まらない理由 仮に22,519,960件を、開始から確認までの約95時間で均等に取得したとすると、1時間あたり約23.7万件、1秒あたり約66件です。実際の取得の速さと分散のさせ方は公表されていません。それでも、送信元を分ければ1か所あたりの要求数は小さくでき、要求の回数だけを数えるレート制限では見落とす量だと分かります。 [OWASP API Security Top 10 2023のAPI4（Unrestricted Resource Consumption）](https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/)は、1つのクライアントや利用者が一定時間に操作できる回数を、業務の必要に合わせて絞るよう求めています。会員情報を返すAPIで業務の実態に沿う指標は、要求の回数よりも「1つの認証情報が1時間に何人分の会員を見たか」です。自分の情報だけを見る一般会員なら、この値は1人のはずです。 ### 認証情報ごとに1時間で参照した異なる会員数を出すSQLと実行結果 次のSQLは、アクセスログ（api\_access）から認証情報ごと・1時間ごとに参照した会員IDの種類数を数え、200人を超えた時間帯だけを残して、最初と最後の時間帯と件数を出します。SQLiteの構文で、distinct\_per\_hour.sqlとして保存します。 ``` WITH hourly AS ( SELECT principal, strftime('%Y-%m-%d %H:00', ts) AS hour, COUNT(DISTINCT member_id) AS members FROM api_access GROUP BY principal, hour ) SELECT principal, MIN(hour) AS first_alert, MAX(hour) AS last_alert, COUNT(*) AS alert_hours, MAX(members) AS max_members_per_hour FROM hourly WHERE members > 200 GROUP BY principal ORDER BY first_alert; ``` 2026年10月16日に、架空のデータで実行しました。会員10万件の表に対し、10月6日0時から13日13時36分までのアクセスログ134,997行を入れています。一般会員3,000人が自分の情報を1日0〜3回参照し、サポート担当が平日9時〜18時に1時間10〜40人を参照します。そこに、1つの会員の認証情報が10月9日10時から13日9時まで、会員IDを順に全件取得する記録を混ぜました。 ``` member:48213 | 2026-10-09 10:00 | 2026-10-13 08:00 | 95 | 1053 ``` 出力は1行だけで、開始した10月9日10時台に最初の該当が出ています。1時間あたり1,053人は1秒あたり0.3回ほどの要求で、回数のレート制限には掛かりにくい速さです。同じデータで正常な利用の最大値を測ると、一般会員は1時間1人、サポート担当は40人でした。 ### しきい値の決め方と通知を受けてから認証情報を止めるまでの手順 しきい値の200は、サポート担当の最大40人に余裕を持たせたサンプルの値です。自社のログで役割ごとの最大値を1か月分測り、一般会員の認証情報と社内の担当者の認証情報で別の値にしてください。一般会員の認証情報が他人の会員IDを1件でも参照していれば、それ自体が認可の不備です。他人の会員IDで操作が通らないかの点検は[セイコーマートの不正アクセスと57万人の会員情報](https://www.issoh.co.jp/tech/details/18093/)で扱いました。 このSQLを1時間ごとに回し、該当が出たら担当者に通知し、該当した認証情報のトークンを失効させる手順を決めておきます。失効の実装と、送信元単位・パス単位のレート制限の設定例は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)にまとめています。日単位で期間を割り出すSQLと、架空会員で初日に気付く仕組みは、[バーガーキングの不正アクセスの記事](https://www.issoh.co.jp/tech/details/18384/)で扱いました。 ## 会員APIの点検を今月中に進める事業者と外部IDaaS任せで後回しにできる事業者 ### 自社で会員DBと会員情報を返すAPIを持ち会員数が数十万件を超える事業者 自社のサーバーに会員DBを置き、アプリやWebから会員情報を返すAPIを持っていて、会員数が数十万件を超えるなら、今月中に次の3点を確かめてください。APIの応答にパスワードやそのハッシュが入っていないか。1つの認証情報が1時間に何人分の会員を見られるかを数えているか。全会員のパスワードを一斉に無効化し、再設定に誘導する手順と画面があるか。今回の事案では再設定サイトに要求が集中しました。 一覧APIで1回に返す件数を絞る対策は[焼肉きんぐの不正アクセスの記事](https://www.issoh.co.jp/tech/details/18134/)で解説しています。社内で答えが出ない項目があり、会員データへの経路を第三者の目で確かめたいときは、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で、APIの返却項目と大量取得への備えを含めて点検できます。 ### 認証と会員管理をIDaaSに任せる小規模サービスで過剰になる場面 会員のパスワードを自社で保存せず、認証と会員管理を外部のIDaaSに任せている小規模なサービスでは、本記事のSQLのような検知を自前で組む運用は過剰です。確かめるのは、IDaaSの管理APIの鍵を誰が持っているか、会員の一括エクスポートを実行できる権限が絞られているか、監査ログが何日残るかの3点で足ります。顧客ID基盤の選び方と会員DBの移行は[CIAMとは](https://www.issoh.co.jp/tech/details/16403/)で扱っています。 ## よくある質問 ソースネクストの不正アクセスについて、会員と会員サービスを運営する担当者から出やすい質問をまとめました。 ### ソースネクストから届いたお詫びメールは本物ですか？ 同社は対象の会員へ10月15日以降、登録メールアドレス宛てに順次お詫びと案内を送っているため、同社名のメールが届くこと自体はあり得ます。ただし同社や関係先を装った不審な連絡にも注意するよう呼びかけています。メールのリンクは開かず、自分でブラウザからソースネクストのサイトを開いてログインするか、専用窓口0120-035-116に電話して確かめてください。 ### 何年も使っていない古いアカウントも対象ですか？ 公式FAQは対象の範囲を「2026年10月13日13時36分までに当社にご登録があるお客様」としており、利用していない期間で除外するとは書いていません。古いアカウントのメールアドレスとパスワードを他のサービスでも使っていた場合は、そちらを変えてください。登録したメールアドレスが分からないときは専用窓口で確認できます。 ### クレジットカードの利用停止や再発行は必要ですか？ 公式FAQは、クレジットカード情報は不正アクセスを受けたシステムに保有しておらず、流出の対象に含まれないため、本件に起因する利用停止や再発行は不要としています。2023年2月の事案ではカード情報が対象でしたが、今回とは別の事案です。明細に覚えのない請求がある場合は、カード会社に問い合わせてください。 ### ソースネクストを退会したい場合はどうすればよいですか？ 公式FAQによると、退会の手続きは専用の問い合わせ窓口のメールまたは電話で受け付けています。電話は0120-035-116で、受付は10時〜18時、土日祝日も受け付けています。退会しても流出した可能性のある情報は戻らないため、同じパスワードを使う他のサービスの変更は退会とは別に済ませてください。 ### 自社の会員APIで同じことが起きないか、何から確かめればよいですか？ 最初に、会員情報を返すAPIの応答にパスワードやハッシュなど画面で使わない項目が入っていないかを、本記事のスクリプトのような許可リストで確かめます。次に、認証情報ごとに1時間で参照した会員の数をログから数えられるかを確かめ、役割ごとの通常の最大値を測ってしきい値を決めます。最後に用意するのは、全会員のパスワードを一斉に無効化するための具体的な手順です。 ## 関連記事 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効](https://www.issoh.co.jp/tech/details/18346/)：APIの認可とレート制限、トークン失効の実装 - [Studio不正アクセスで全顧客の情報流出か｜パスワード・APIキー・Webhook URLを今日替える手順](https://www.issoh.co.jp/tech/details/18389/)：同日公表の事案と、SaaSに預けたAPIキー・Webhook URLの入れ替え - [バーガーキング不正アクセスで約1,118万件の情報漏洩｜対象確認・案内メールの真偽と運営側のログ点検](https://www.issoh.co.jp/tech/details/18384/)：不正アクセスの期間を割り出すSQLと架空会員での検知 - [銀のさら不正アクセス：最大650万件の対象確認と窓口、パスワード変更の手順](https://www.issoh.co.jp/tech/details/18365/)：パスワードが漏れたときの危険度と使い回しの確認 - [セイコーマートの不正アクセスと57万人の会員情報｜アプリAPIの認可を点検する手順](https://www.issoh.co.jp/tech/details/18093/)：他人の会員IDで操作が通らないかの点検 - [Gensparkの代理店はどこ？ソースネクストと公式直販の違い・法人の買い方【2026年10月】](https://www.issoh.co.jp/tech/details/10783/)：ソースネクスト経由で購入したサービスの扱い --- 出典: [ソースネクスト不正アクセスで最大2,252万件流出｜ログインできない理由・パスワード再設定と会員APIの点検]()（株式会社一創）