株式会社ファンくるの会員管理システムへの不正アクセス（会員情報421万件流出）
公表日
「ファンくる」の会員登録用APIにプログラムの不備があり、不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。外部の攻撃者だけでなく、内部の人が権限を超えて行う場合もあります。日本では「不正アクセス禁止法」で禁止されています。公表文の「不正アクセス」は手口の名前ではなく、どう侵入されたかは別に書かれます。によって会員情報421万7,663件が流出しました。
対象者は？
「ファンくる」の直接会員約103万件（氏名、メールアドレス、暗号化パスワード等）および提携サービス（ECナビ「ポンポンモニター」、ポイントタウン「モニターで貯める」等）の連携利用者約318万件（連携ID、性別、登録日）。退会者やクレジットカード情報は含まれていません。
「ファンくる」および提携各社から、対象となる会員宛てに登録メールアドレスへ順次案内が送信されています。
いますぐできること
- 「ファンくる」に登録しているメールアドレス宛てに不審な連絡やフィッシング銀行・通販サイト・宅配業者・公的機関などを装ったメールやSMSを送り、本物そっくりの偽サイトに誘導して、IDやパスワード、カード番号などを入力させる手口です。SMSを使うものは「スミッシング」、電話を使うものは「ビッシング」とも呼ばれます。メールが届いていないか注意する。
- 他のWebサービスで同じパスワードを使い回している場合は、念のためパスワードを変更する。
何が起きたのか
2026年10月30日から31日にかけて、モニターサービス「ファンくる」の会員登録機能で使われていたAPIに外部から不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。外部の攻撃者だけでなく、内部の人が権限を超えて行う場合もあります。日本では「不正アクセス禁止法」で禁止されています。公表文の「不正アクセス」は手口の名前ではなく、どう侵入されたかは別に書かれます。が行われました。11月1日未明に異常なアクセスを検知した運営元は通信を遮断し、安全確保のためサービス全体を緊急停止しました。プログラムの修正と全機能の点検を経て11月5日にサービスを再開し、11月9日に提携先の連携情報を含めた確定被害規模を公表しました。
なぜ起きたのか・なぜ広がったのか
会員登録の画面で情報を参照するための特定のAPIプログラムにおいて、適切な権限確認を行わない脆弱性がありました。また、提携先との重複登録を防ぐ目的で同一の基盤上に連携会員の識別情報も保持していたため、単一の窓口から連携会員のデータまで参照・取得される事態となりました。
いまの状況2026-11-09 時点続報待ち
原因となったAPIの改修や全APIの安全性点検は完了しており、2026年11月5日よりサービスは再開されています。公表時点で流出情報を悪用した二次被害は確認されていません。なお、停止期間に伴う救済措置として、モニターの提出期限やポイントの有効期限が11月9日まで延長されました。
企業として考えたいこと
自社サイトやアプリの登録フローなどで使われているAPIに、ログインや権限確認なしで顧客データを引き出せてしまう窓口が残っていませんか？
技術的な要約
覆面調査・モニターサービス「ファンくる」を運営する株式会社ファンくるは、会員登録フロー中に利用する参照Web APIの脆弱性を突かれ、第三者による不正アクセスを受けたと発表した。2026年10月30日から10月31日にかけて会員情報が不正に取得され、直接会員1,030,741件およびパートナー連携会員3,186,922件の合計4,217,663件の情報流出が確定した。直接会員のデータには氏名、メールアドレス、ハッシュ化パスワードなどが含まれ、パートナー連携会員については連携ID、性別、会員登録日が含まれていた。同社は2026年11月1日に異常アクセスを検知して通信遮断とシステム緊急停止を実施し、APIの認可制御修正や全Web APIに対するソースコード監査（SAST）を経て11月5日にサービスを再開した。
攻撃の分類
- 侵入口
- 管理画面/API公表で確認会員登録フロー中に利用する特定の参照Web API（1エンドポイント）におけるプログラムの脆弱性（認可制御の不備）
- 脆弱性
- CVE 非公表公表で確認ファンくる会員登録フロー用参照Web API特定の参照Web API（1エンドポイント）における認可制御の脆弱性。具体的な脆弱性識別番号や実装内容は非公表
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- あり 不正アクセスへの二次被害防止のため、2026年11月1日10時43分から11月5日にかけてモニター体験サイト「ファンくる」の閲覧および全機能の利用を停止した。これに伴い、モニター提出期限および有効期限を迎えたポイントについて2026年11月9日まで延長する救済措置が取られた。期間：2026-11-01T10:43+09:00 - 2026-11-05
- データ
- 確定上限 4,217,663確定 4,217,663件会員IDメールハッシュ化PW氏名性別その他合計流出確定件数は4,217,663件（退会者を除く）。内訳は直接会員情報1,030,741件（会員ID、メールアドレス、ハッシュ化パスワード、氏名、性別、郵便番号、電話番号の下4桁）、およびパートナー連携会員情報3,186,922件（連携ID、性別、会員登録日）。
- 波及先
- 2 サービス
- ECナビ（株式会社DIGITALIO）の「ポンポンモニター」：識別ID、性別、初回利用日が対象に含まれた
- ポイントタウン（GMOメディア株式会社）の「モニターで貯める」：ファンくる社付与ID、性別区分番号、初回連携日が対象に含まれた
- 金銭影響
- —
- サプライチェーン
- 株式会社ファンくるのAPI脆弱性による不正アクセスにより、同社サービスと連携していた外部パートナー（ECナビ、ポイントタウン等）の会員連携データ3,186,922件が影響を受けた。
時系列
技術解説
単一Web APIの認可不備と大量データ取得の経緯 事実
株式会社ファンくるの公表によると、不正アクセスの直接的な原因は会員登録フロー中に利用されていた特定の参照Web API（1エンドポイント）における認可制御の脆弱性であった。第三者は2026年10月30日10時52分から翌31日19時45分までの約33時間にわたり、この脆弱性を突いて会員情報を不正に取得した。流出確定件数は合計4,217,663件（退会者を除く）に上る。内訳はファンくる直接会員1,030,741件と、外部パートナー連携会員3,186,922件である。直接会員のデータには会員ID、メールアドレス、ハッシュ化済みパスワード、氏名、性別、郵便番号、マスキングされた下4桁以外の電話番号が含まれていた。一方、パートナー連携会員のデータは各連携先における識別用ID、性別区分、会員登録日であり、直接個人を特定できる情報や認証トークン、どの連携元企業であるかを識別する所属コードは含まれていなかった。
共通データ基盤の仕様とパートナー連携会員への被害拡大要因 解釈
本件で流出規模が420万件超まで拡大した背景には、単一エンドポイントの実装不備に加え、データ統合基盤の設計仕様が関係している。ファンくるでは外部提携先（ECナビ、ポイントタウン等）との連携時における重複登録防止や整合性管理のため、サービス基盤上に共通の会員識別子と基本属性（性別・登録日）を一元保持する仕様を採用していた。このため、参照APIにおける認可チェックの欠落が、自社直接会員にとどまらず連携基盤内の全パートナー会員データへのアクセスに波及したと考えられる。また、攻撃者が30時間以上にわたり大量のリクエストを送信してデータを取得できていた点から、単一セッションやIPアドレスからの連続リクエストを検知・抑止するAPIスロットリング（レート制限）や異常検知の閾値設定が十分機能していなかった可能性が推察される。
異常検知後のシステム全停止と網羅的コード監査（SAST）による復旧 解釈
インシデント発覚後の技術的対応において、ファンくるは異常トラフィック検知から約1時間半後の11月1日1時36分に通信を遮断し、同日10時43分にはサービス全機能を緊急停止した。二次被害防止のために中核サービスを即座に全面停止した判断は迅速であった。さらに、問題となったエンドポイントの認可制御を修正しただけでなく、未認証リクエストを遮断する攻撃再現テスト（PoC検証）を実施し、保有するすべてのWeb APIエンドポイントを対象にした静的ソースコード監査（SAST）を行って同種脆弱性の不存在を確認した上で、11月5日にサービスを再開している。このように場当たり的なパッチ当てにとどまらず、全APIへの網羅的な監査を経て再開に至った対応は手堅い初動対応と評価できる。
対応
- 封じ込め
- 異常アクセス検知後に通信遮断を実施し、サービス全体を緊急停止した。該当APIに対して未認証リクエストを遮断する認可制御を実装してPoC検証を行ったほか、全Web APIに対するソースコード監査（SAST）を実施した。
- 公表の仕方
- 2026年11月2日に第一報を公表。11月4日に第二報で直接会員の被害状況を公表し、11月9日に第三報としてパートナー連携会員を含む全体の被害規模（421万件超）および再発防止策を公表した。提携先企業（ポイントタウン、ECナビ）からも個別に告知が行われた。
- 当局対応
- 個人情報保護委員会
- 管轄警察署
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 公開・登録用Web APIにおける厳格な認可制御の徹底 | 会員登録や入力支援など公開領域に設置するAPIであっても、未認証リクエストや他者権限によるデータ参照を防止するため、アクセス権限を厳密に検証する認可ミドルウェアを適用し、CIパイプラインで自動検査する。 |
| APIエンドポイントへの過剰アクセスを防ぐレート制限（スロットリング）の導入 | APIゲートウェイやWAFにおいて、IPアドレスやトークン単位で単位時間あたりのリクエスト上限を設定し、連番走査や大量取得の兆候を検知した場合にHTTP 429応答を返して通信を自動遮断する。 |
| パートナー連携データの論理的・物理的な分離と最小限の露出設計 | 他社連携会員データと自社会員データでアクセス経路やデータストアを分離し、APIレスポンスに含まれる属性項目を用途ごとの必要最小限（プロジェクション）に制限して不要な属性露出を遮断する。 |
| 全Web APIに対する静的解析（SAST）と攻撃再現テスト（PoC）の定常運用 | 開発プロセスにSASTツールを組み込み、認可アノテーションの漏れを機械的に検出するカスタムルールを配備する。また脆弱性修正時は未認証・境界外IDによるアクセス再現テストコードを作成して自動回帰テストを実施する。 |
自組織などでの確認項目
- 自社の会員登録フローや外部公開機能で利用されているAPIの中に、未認証や認可不備の状態で他者のデータを参照できるエンドポイントが存在しないか。
- APIゲートウェイやリバースプロキシで、会員IDなどのパラメータ走査や短時間での大量リクエストを検知・自動遮断するレート制限（スロットリング）が全APIに配備されているか。
- 外部提携先やパートナーから預かっている連携データが、自社の単一Web API脆弱性によってまとめて参照・漏洩し得るデータモデルになっていないか。
未解明点
- 攻撃者が約33時間にわたって大量の会員データを取得する間、WAFやインフラ監視による自動ブロックが即座に作動しなかった技術的要因。
出典
- 1株式会社DIGITALIO2026-11-09公式本文確認済
- 2ビジネス＋IT2026-11-06報道本文確認済
- 3セキュリティ対策Lab2026-11-10報道本文確認済
- 4株式会社ファンくる2026-11-04公式本文確認済
- 5株式会社ファンくる2026-11-09公式本文確認済
- 6株式会社ファンくる2026-11-02公式本文確認済
- 7GMOメディア株式会社2026-11-05公式本文確認済