CAPCOM ID侵害が通販へ波及｜第二報で19件の顧客情報流出を公表

カプコンは2026年10月23日、共通アカウント「CAPCOM ID」への不正アクセスに関する第二報を公表しました。不正にパスワードが変更された196アカウントのうち、19件で通販サイト「イーカプコン」のマイページにも第三者がアクセスし、住所や購入履歴などが漏えいしたとしています。共通ID側の被害だけを調べて終わらず、接続先のサービスまで影響を確認する必要性が分かる事案です。

本稿は、カプコンの10月22日の第一報と10月23日の第二報を2026年10月24日に直接確認して整理したセキュリティニュースです。公表された被害と、Webサービス運営者向けの分析・提案を分けて説明します。攻撃の具体的な侵入経路や、不正なパスワード変更を可能にした技術的原因は、確認した両資料では説明されていません。

第二報で増えたのは通販側の具体的な影響

CAPCOM IDは、カプコンのWebサービスや一部のオンラインゲームで使う登録制の共通アカウントです。10月22日の第一報では、全世界で11,774,247件のメールアドレスと、アカウント作成・最終ログインの日時、ログイン回数、最終ログイン時のクライアントIPの漏えいが公表されました。そのうち43件では、生年月日などの追加情報も対象でした。

また第一報では、196件でログインパスワードの不正変更を確認し、該当アカウントのパスワードは既にリセットしたと説明していました。利用者が設定していたパスワードそのものの漏えいは確認されていない、という説明と、不正な変更が起きたという説明が併存しています。両者は矛盾する情報ではなく、調べている事象が異なります。

第二報で判明したのは、その不正変更から関連サービスへ及んだ影響です。国内19件について、イーカプコンのマイページへの不正アクセスと、氏名、氏名のカナ、電話番号、郵便番号、住所、性別、生年月日、購入履歴、問い合わせ履歴、会員アドレス帳の漏えいを公表しました。クレジットカード情報は対象に含まれないとしています。

同社は、その他のアカウントではパスワードの不正変更による情報漏えいを確認しなかったと説明しています。この記述は、第一報で公表したメールアドレス等の漏えいがなかったという意味ではありません。どのアクセスによって、どの情報が影響したかを分けて読む必要があります。

三つの件数を足して被害人数にしない

11,774,247件、196件、19件は、独立した被害集団を表す数字ではありません。第一報の大きな対象の中に不正変更された196アカウントがあり、第二報の19件はそのうちの一部です。また、第一報の43件と196件の重なり方は資料に示されていません。これらを合計して被害人数とすることはできません。

会員アドレス帳という情報項目も、19人分の住所だけという意味に読み替えない方が適切です。一方で、住所録に何人分が登録されていたかは公表されておらず、対象者数を推計する根拠もありません。確認できるのは、公表されたアカウントの件数と情報の種類までです。

本サイトの分析として重要なのは、件数の大小と情報の機微性を別に評価することです。メールアドレスの広い漏えいと、少数でも住所・購入・問い合わせ内容が結び付く漏えいでは、その後の説明や利用者への案内が変わります。大きな数字だけを見出しにすると、対応を変える第二報の意味を見落とします。

発見から公表と追加調査の完了を区別する

• 10月19日：同社が不審な痕跡を発見し、同日に不正アクセスを確認。遮断と調査、緊急対策に着手。
• 10月20日：対策本部を設け、情報漏えいと一部の不正なパスワード変更を確認。
• 10月21日：警察と個人情報保護委員会へ報告。
• 10月22日：第一報を公表。
• 10月23日：通販側の19件の影響を第二報で公表。

第一報では、緊急対策と攻撃手段への対応を完了し、CAPCOM IDを使うサービスとゲームの利用は継続できると説明しています。第二報では、影響範囲の調査が完了した一方で、関連サービスの監視を続けるとしています。対策の完了、影響調査の完了、監視の継続は、それぞれ違う状態です。

この記事の確認日は10月24日ですが、事件の初回公表日は10月22日、追加の影響が公表された日は10月23日です。新たに10月24日に被害が起きたと伝える記事ではありません。今後の更新を確認する際も、公表日と、その資料が対象にしている事実の時点を分けてください。

利用者は個別連絡と公式の入口を確認する

カプコンは対象となる利用者へ順次個別に連絡するとしています。第二報では、漏えい情報を使い、同社や関係先を装ったメールだけでなく、ショートメッセージや電話が届く可能性も注意点として挙げています。これは二次被害の可能性への注意喚起であり、これらの手段で既に被害が発生したという公表ではありません。

本サイトからの提案は、届いた連絡だけを入口にせず、ブックマークや自分で確認した公式サイトから告知と問い合わせ先へ進むことです。住所や購入した商品の名前を知っている相手でも、それだけで正規のサポート担当とは判断しません。履歴と組み合わされた連絡では、内容のもっともらしさと送信元の真正性を切り分けます。

身に覚えのないパスワード変更やログイン不能がある場合は、通知の時刻と状況を記録し、公式窓口へ相談します。パスワードや認証コードを相手へ渡して本人確認を済ませようとせず、公式の復旧手順を使ってください。本稿では、公式資料で確認できない一律の操作や、未確認の復旧URLを案内しません。

同じパスワードを他サービスで使っている場合、その使い回しを解消することは一般的な対策です。ただし、それを今回パスワードが流出した証拠とは扱いません。カード情報が対象外という説明も、住所や購入履歴を悪用した連絡へ注意する必要がなくなったという意味にはなりません。

運営者は共通IDの停止範囲を接続先まで確認する

ここからは、今回の攻撃原因の推定ではなく、自社で共通IDを使うWebサービスを運営する場合の点検提案です。今回の事案に特定の認証方式や連携プロトコルが使われたと断定するものではありません。確認資料には、セッションやトークンの失効処理の詳細も記載されていません。

最初に、共通IDから到達できるサービスを一覧にします。EC、会員ページ、問い合わせ履歴、配送先、外部連携などについて、保持する情報と担当者を対応させます。同じ会社の中でも、共通IDの担当だけでは各サービスの閲覧履歴を調べられないことがあるため、調査を依頼する窓口まで用意します。

次に、アカウント停止やパスワードの強制リセットで、各サービスが既に発行したログイン状態をどう扱うか確認します。共通ID側で再ログインできなくしても、接続先が別の有効なセッションを持つ構成なら、既存のアクセスを止める作業が別に必要です。停止したつもりの状態を、画面の案内だけで判断しないことが重要です。

OWASPのAuthentication Cheat Sheetは、不審な活動やアカウント復旧などの高リスクな事象の後に再認証を求める考え方と、機微な操作を守る対策を説明しています。自社では、パスワード・メールアドレス・配送先の変更、購入や個人情報へのアクセスに、どの確認を要求するかを整理します。

追加の本人確認を設ければすべて解決するわけではありません。復旧手続きでその確認を迂回できたり、停止情報が別サービスへ届かなかったりすれば、境界は残ります。共通IDの機能、接続先の判断、サポート担当の操作を一つの対応表へ載せ、誰がどこまで止めるかを定めます。

調査は認証成功の件数から情報へのアクセスへ進める

本サイトでは、共通IDの操作記録と、接続先のマイページ・APIのアクセス記録を、内部のアカウント識別子と時刻で照合する方法を提案します。ログインした事実だけでは、住所や履歴を読んだかは分かりません。どの画面やAPIがどの情報を返すかを把握し、必要な監査情報が残っているか確認します。

反対に、ログに該当記録がないことだけで、アクセスがなかったと確定しません。保存期間、ログの対象範囲、CDNやキャッシュ、時刻のずれ、記録欠損を調べます。調査結果は、確認できたアクセス、確認できなかった範囲、追加調査が必要な範囲に分けて管理します。

会員が住所録や問い合わせ内容を保持できるサービスでは、アカウント一件の侵害が、基本プロフィール以外の情報へ届く場合があります。保持期間、必要な情報の範囲、画面で一度に表示する量を見直すことも、被害を限定するための検討事項です。今回のサービスがどのような保管設計だったかは公表資料から判断できません。

利用者向けの案内では、最初に判明した事実だけで完了とせず、関連サービスの確認が進んだ段階で何を更新するかを決めておきます。被害件数の変更、情報項目の追加、利用者に必要な行動を明確にし、古い告知と新しい告知の関係を説明できることが重要です。

現時点で確定できないこと

確認した公式資料からは、侵入に使われた脆弱性、CVE、利用者の認証情報が不正変更された仕組み、攻撃者やAI利用の有無は確定できません。パスワードリスト攻撃、認証回避、管理機能の悪用など、もっともらしい説明を原因として補うことはしません。利用者が弱いパスワードを使っていたと決めつける根拠もありません。

Web運営者にとっての具体的な確認点は、共通IDを守ることに加え、そのIDで到達できる情報と、停止・復旧・調査の範囲を一致させることです。今回の第二報は、共通アカウント側の不正変更と接続先での情報流出を区別して公表しており、自社の調査範囲を点検する際の参考になります。

関連記事

ログアウト後も使えるセッションを残さないための失効設計では、ログアウトや強制停止後に古い資格情報を受け付けないための確認を扱います。2026年10月18日時点の資料に基づく恒久対策で、今回の事案の原因を説明する記事ではありません。