2026年9月13日にHave I Been Pwnedに記録が追加されましたChess.com (2026)：730万行、460万のユニークなメールアドレス。ダンプにはパスワードは含まれておらず、ハッシュもなく、支払いデータもありません。そして、どうやらハッキングもなかったようです：データは通常のリクエストを通じて、9日間連続で収集されました。これは「漏洩」と「システムへの侵入」が異なるものであり、メカニズムを理解する必要がある場合です。
公開された内容
アーカイブは2026年8月12日にサイバー犯罪フォーラムに登場し、Telegramを通じて広まりました。解凍されたファイルは15.5GB（7-Zipで744MB）で、中には7,337,395件のレコードがあり、各レコードには38のフィールドがあります。
- メールアドレス — 約75%のレコード（460万ユニーク）。
- ユーザー名、実名、ユーザーID、UUID。
- 国、ロケーション、インターフェースの言語。
- レーティング、称号、ゲームレベル、プレミアムサブスクリプションのステータス。
- 登録日と最終ログイン日 — 2026年8月まで。
- Google Ad Managerの広告セグメント — gam_audiencesおよびaudiences_member_ofフィールド。
最後のポイントは最も予想外のものでした。これは「トライアルに適している」、「退会したユーザー」、レーティングの範囲、コーチのヒントに関する実験への参加などの内部マーケティングラベルです。ユーザーには見えず、公開APIにも存在せず、「自分のセグメントを確認して修正する」設定はありません。つまり、ダンプにはプロファイルだけでなく、プラットフォームが広告のためにプレイヤーをどのようにラベル付けしているかも含まれています。
なぜこれはスクレイピングであり、ハッキングではないのか：三つの証拠
ダンプを分析したアナリストは、販売者の言葉ではなく、データの構造に基づいていました。
- 収集のリズム。 レコードは2026年7月26日から8月3日までの9日間にわたり、72,000から267,000の不均一なバッチで日付が付けられています。一度にデータベースをエクスポートすることはこのようには見えません：侵害されたストレージからのダンプは、ある瞬間の一つのスライスです。
- 重複。 7.4%のレコードが重複しています：同じアカウントが異なる日にエクスポートされていました。これは、テーブルのエクスポートではなく、スライディングウィンドウを使用した自動化されたクロールの兆候です。
- 初版のUUID。 Chess.comの識別子には組み込まれたタイムスタンプが含まれています。サンプルのチェックにより、169,287のUUIDがアカウントの登録日と3秒以内の精度で一致していることが確認されました。このような相関関係を数百万のレコードで偽造することは不可能です — データは本物ですが、合法的なリクエストによって取得されました。
HIBPはもう一つの論拠を追加しました：ダンプ内のメールアドレスの99%は過去の漏洩で既に見られたものでした。プロダクションから直接引き上げられたデータベースでは、割合は異なるはずです — ここでは、アドレスが外部から来ており、アカウントと照合されていることが明らかです。
メカニズム：友達を見つける機能が検索インデックスとして機能する
ベクトルは2023年のインシデントでも知られており、その際にChess.comから最初に82万8千件、次に約47万6千件の同一のフィールド構造を持つレコードが漏洩しました。当時、会社は「これはデータの漏洩ではありません。私たちのインフラストラクチャ、アカウント、パスワードのようなデータは安全です」と明言しました。形式的には正しいです。
スキームはシンプルです。プラットフォームには知り合いを探す機能があります：メールアドレスをアップロードすると、サービスはそのユーザーが存在するかどうかを返答し、プロファイルを表示します。他人のメールのデータベースを取得し（公開されているものは数十億あります — これが過去の漏洩との99%の一致の理由です）、この機能を通じて処理し、豊富なプロファイルを得ます：名前、国、レーティング、最終ログイン日、広告セグメント。
ここでの個々の操作は攻撃には見えません。しかし、何百万もの繰り返しによって攻撃となります。ダンプを分析した専門家は、直接的な原因を特定しました：過小評価された列挙抵抗、レート制限、遅い広範な収集の監視です。つまり、ハッキングに対する防御はありますが、忍耐強い試行に対する防御はありません。
これは単なる例ではなく、問題のクラスです
同じクラスの最も大きなデモンストレーションは、ウィーン大学によるWhatsAppに関する研究です。チームはリバースエンジニアリングAPIを通じて、1時間あたり1億以上の電話番号に問い合わせを行い、1つの大学のサーバーと5つの認証されたアカウントを使用しました。その結果、35億のアクティブアカウントが列挙されました：番号、プロファイル写真、公開鍵。レート制限は一度も機能しませんでした。この実験は2024年12月から2025年4月まで行われ、Metaは2025年10月に静かに穴を閉じ、結果はNDSS 2026で発表されました。
同じ研究の示唆に富んだ詳細：2021年のFacebookの古い漏洩からの電話番号の58%は、WhatsAppでまだアクティブでした。一度収集されたデータは古くならず、次の試行のための入力素材となります。Chess.comは2026年にまさにこれに苦しみました：他の誰かによって以前に収集されたリストで攻撃されました。
合法的にデータを収集する人々にとっての変化
このようなインシデントは、悪意のある者に打撃を与えるのではなく、公開データを扱うすべての人々に影響を与えます。プラットフォームの反応は予測可能です：報道の後、制限が厳しくなり、行動分析が導入され、検索と発見のエンドポイントは認証とキャプチャの背後に隠されます。あなたの慎重な公開商品カードのパーサーは、メールの試行とは関係ありませんが、新しいルールの下で他のすべてと一緒に対象となります。この問題に関する一般的なアプローチについては、APIの制限とその取り扱いに関する分析で述べています。
したがって、明確な境界を維持することが重要です — それは技術によるものではなく、人々の識別子に対して何をするかによって決まります。
- 公開データ — サービスが匿名の訪問者に直接リンクで表示するもの：商品カード、価格、公開プロファイル、オープンポスト。収集するのは正常です。
- 列挙 — 検索機能に外部のメール、電話、またはIDのリストを挿入して、それらが誰に属するかを知ることです。これはもはや公開データの収集ではなく、個人識別子の照合であり、GDPRに類似した法域では適切に分類されます — エンドポイントがオープンであるかどうかにかかわらず。
- 隠しフィールド。 Chess.comの広告セグメントは、いかなる形でも公開されていません。APIの応答からインターフェースに存在しないものが返される場合、それは「ボーナス」ではなく、停止する信号です。
誠実な収集のための実用的なチェックリスト：他人の連絡先情報を検索および発見機能に挿入しない；サービスが劣化せずに耐えられるペースを維持する；robots.txtと公開オファーを尊重する；インターフェースに表示されるフィールドのみを取得する；余分なものを保存しない。法的な側面については、プロキシを通じてデータを合法的に収集する方法に関する資料で詳しく説明しています。
このダンプにあなたのアドレスが含まれている場合の対処法
ダンプにはパスワードが含まれていないため、単に漏洩した事実のためにパスワードを変更する意味はあまりありませんが、リスクはゼロではなく、特有のものです。
- Have I Been Pwnedでアドレスを確認してください。 記録はChess.com (2026)と呼ばれ、2026年9月13日にアップロードされ、460万のアドレスがあります。
- ターゲットを絞ったフィッシングを待つ。 「メール + 実名 + 国 + レーティング + 最終ログイン日 + サブスクリプションのステータス」の組み合わせは、プラットフォームからのように見える説得力のあるメールのための材料です。通常の配信はこのようには見えません；あなたのレーティングを知っているメールはそう見えます。
- このアドレスが他にどこで使用されているかを確認してください。 99%のアドレスは過去の漏洩で既に見られています — つまり、あなたのメールは他人のリストに長い間存在しており、次のプラットフォームでオープンな検索機能を通じて処理されるでしょう。
- 可能な限り、公開プロファイルからメールを解除してください。 サービスがメールや電話で自分を検索できないようにすることを許可している場合、それはまさにあなたのためにこのベクトルをオフにするスイッチです。
自分のサービスを構築している人々にとって、このインシデントからの短い結論はさらにシンプルです：外部識別子に対して「そのユーザーは存在し、これが彼のカードです」と応答する任意の機能は、外部からアクセス可能なあなたのデータベースの検索インデックスです。それはアカウントとIPサブネットに対するレート制限を必要とし、単一のアドレスだけでなく、広範な遅いサンプリングの監視も必要です。これらは時間単位のメトリクスでは正常な背景のように見えます。
プロキシの役割 — そしてそれが決して何でないか
はっきりと言っておくべきことがあります。こうしたインシデントの後には必ず「すべてはプロキシを通じて行われている」という主張が浮上します。プロキシは三つのタスクを解決します：IPアドレスの評判とASN、リクエストの地理的関連付け、合法的な収集量で一つのアドレスの制限を超えないように負荷を分散します。レジデンシャルプロキシは、サイトが地域によって異なるコンテンツを提供したり、データセンターのサブネットを切り取ったりする場合に必要です — たとえば、価格の監視や異なる国での結果の表示の際です。
プロキシが行わないこと — 他人のメールの試行を合法的な収集に変えたり、結果から守ったりすることはありません。Chess.comのケースでは、アドレスの分散がデータを9日間目立たずに引き出すことを可能にした可能性がありますが、これはプラットフォームの防御が弱いという特性であり、そのようなシナリオを支持するものではありません。技術的には、列挙は通常のトラフィックと区別がつかないのは、誰かがボリュームをログと照合するまでです — そしてその後は、制限についての議論ではなく、規制当局についての議論が始まります。
結論
Chess.comの歴史は、同じ攻撃面での三度目のエピソードであり、単一のハッキングなしに起こりました。プラットフォームにとっての厳しい教訓は、インフラストラクチャへの侵入だけをインシデントと見なす防御の輪は、どのようにデータが部分的に持ち出されるかを見逃すということです。データをプロフェッショナルに収集する人々にとっても実用的な教訓があります：制限は価格のパーサーによるものではなく、このような歴史によって厳しくなり、各新しい波のコストはデータ収集の全業界にかかります。公開収集と個人識別子の試行を分けることは、エチケットの問題ではなく、公開データが本当にアクセス可能であり続けるかどうかの問題です。