Le 13 septembre 2026, une entrée Chess.com (2026) est apparue sur Have I Been Pwned : 7,3 millions de lignes, 4,6 millions d'adresses email uniques. Il n'y a pas de mots de passe dans le dump, pas de hachages, pas de données de paiement. Et il semble qu'il n'y ait pas eu de piratage non plus : les données ont été collectées pendant neuf jours consécutifs par des requêtes ordinaires à un service en ligne. C'est un cas où « fuite » et « intrusion » sont des choses différentes, et il est important de comprendre la mécanique.
Qu'est-ce qui a été rendu public
L'archive est apparue sur un forum de cybercriminalité le 12 août 2026 et a été diffusée via Telegram. Le fichier décompressé fait 15,5 Go (744 Mo en 7-Zip), contenant 7 337 395 enregistrements avec 38 champs chacun.
- Adresses email — environ 75 % des enregistrements (4,6 millions uniques).
- Noms d'utilisateur, vrais noms, ID utilisateur et UUID.
- Pays, localisation, langue de l'interface.
- Classements, titres, niveau de jeu, statut d'abonnement premium.
- Dates d'inscription et de dernière connexion — jusqu'en août 2026.
- Segments publicitaires Google Ad Manager — champs gam_audiences et audiences_member_of.
Le dernier point est le plus inattendu. Ce sont des étiquettes marketing internes comme « adapté pour une période d'essai », « utilisateur parti », plages de classement, participation à des expériences avec des conseils d'entraîneur. Les utilisateurs ne les voient pas, elles ne figurent pas dans l'API publique, et il n'existe pas de paramètres pour « voir et corriger son segment ». Cela signifie que non seulement le profil a été inclus, mais aussi la façon dont la plateforme elle-même classe le joueur pour la publicité.
Pourquoi c'est du scraping et non un piratage : trois preuves
Les analystes qui ont examiné le dump se sont basés non sur les paroles du vendeur, mais sur la structure des données.
- Rythme de collecte. Les enregistrements sont datés de neuf jours consécutifs — du 26 juillet au 3 août 2026, avec des lots irréguliers allant de 72 à 267 000 par jour. Une exportation unique de la base ne se présente pas ainsi : un dump d'un stockage compromis est un seul instantané à un moment donné.
- Doubles. 7,4 % des enregistrements se répètent : le même compte apparaissait dans l'exportation à différents jours. C'est un signe d'un parcours automatisé avec une fenêtre glissante, et non d'une exportation de tableau.
- UUID de première version. Les identifiants Chess.com contiennent un horodatage intégré. Un échantillonnage a montré : 169 287 sur 169 289 UUID correspondaient à la date d'inscription du compte avec une précision de trois secondes. Falsifier une telle corrélation sur des millions d'enregistrements est impossible — les données sont réelles, mais obtenues par des requêtes légales.
Dans HIBP, un autre argument a été ajouté : 99 % des adresses email du dump avaient déjà été rencontrées dans des fuites précédentes. Pour une base extraite directement de la production, la part serait différente — ici, il est évident que les adresses proviennent de l'extérieur et ont été mises en correspondance avec des comptes.
Mécanique : la fonction « trouver des amis » comme index de recherche
Le vecteur est déjà connu depuis l'incident de 2023, lorsque Chess.com a d'abord perdu 828 000, puis environ 476 000 enregistrements avec une structure de champs identique. À l'époque, la société a déclaré clairement : « Ce n'est PAS une fuite de données. Notre infrastructure, nos comptes et les données comme les mots de passe sont en sécurité ». Formelement — c'est vrai.
Le schéma est simple. La plateforme a une fonction de recherche de connaissances : vous téléchargez une adresse email, le service répond s'il existe un tel utilisateur et affiche son profil. Prenons une base d'emails externe (il y en a des milliards en accès libre — d'où les 99 % de correspondances avec des fuites précédentes), passons-la par cette fonction et obtenons en sortie un profil enrichi : nom, pays, classement, date de dernière connexion, segment publicitaire.
Aucune opération individuelle ici ne ressemble à une attaque. Cela devient une attaque à des millions de répétitions. Les experts qui ont examiné le dump ont désigné le coupable : une résistance à l'énumération sous-estimée, une limitation de rythme et une surveillance des collectes lentes et larges. Cela signifie qu'il existe une protection contre le piratage, mais pas contre une exploration patiente.
Ce n'est pas un cas isolé — c'est une classe de problèmes
La plus grande démonstration de la même classe est l'étude de l'Université de Vienne sur WhatsApp. L'équipe, grâce à l'ingénierie inverse de l'API de découverte de contacts, interrogeait plus de 100 millions de numéros de téléphone par heure, utilisant un serveur universitaire et cinq comptes authentifiés. Le résultat — énumération de 3,5 milliards de comptes actifs : numéros, photos de profils, clés publiques. La limitation de rythme n'a jamais fonctionné. L'expérience a eu lieu de décembre 2024 à avril 2025, Meta a discrètement colmaté la brèche en octobre 2025, et le travail a été présenté à NDSS 2026.
Un détail révélateur de la même étude : 58 % des numéros de téléphone de l'ancienne fuite de Facebook de 2021 étaient encore actifs sur WhatsApp. Les données, collectées une fois, ne deviennent pas obsolètes — elles deviennent le matériau d'entrée pour la prochaine exploration. Chess.com en 2026 a souffert exactement de cela : il a été attaqué avec une liste collectée par quelqu'un d'autre auparavant.
Qu'est-ce que cela change pour ceux qui collectent des données légalement
Chaque incident de ce type ne frappe pas le malfaiteur, mais tous ceux qui travaillent avec des données publiques. La réaction des plateformes est prévisible : après la divulgation, les limites sont resserrées, une analyse comportementale est mise en place, les points d'accès de recherche et de découverte sont cachés derrière une authentification et un captcha. Votre parseur soigné de cartes de produits publiques n'a rien à voir avec l'exploration d'emails — mais il sera soumis à la nouvelle règle avec tous les autres. Nous avons écrit sur les approches générales à ce problème dans notre analyse des limites API et de leur gestion.
Il est donc important de maintenir une frontière claire — elle ne passe pas par la technique, mais par ce que vous faites avec les identifiants des personnes.
- Données publiques — ce que le service montre à un visiteur anonyme via un lien direct : fiche produit, prix, profil public, post ouvert. Collecter — c'est normal.
- Énumération — substitution d'une liste externe d'emails, de téléphones ou d'ID dans une fonction de recherche pour savoir à qui ils appartiennent. Ce n'est plus une collecte de données publiques, mais une mise en correspondance d'identifiants personnels, et dans les juridictions avec un régime similaire au RGPD, cela est qualifié en conséquence — peu importe que le point d'accès soit ouvert.
- Champs cachés. Les segments publicitaires de Chess.com n'étaient publics sous aucune forme. Si la réponse de l'API contient des informations non visibles dans l'interface, ce n'est pas un « bonus », mais un signal pour s'arrêter.
Une liste de contrôle pratique pour une collecte de données de bonne foi : ne substituez pas les coordonnées d'autrui dans les fonctions de recherche et de découverte ; maintenez un rythme que le service peut supporter sans dégradation ; respectez le robots.txt et l'offre publique ; ne collectez que les champs visibles dans l'interface ; ne conservez pas de données superflues. Nous avons examiné en détail l'aspect juridique de la question dans notre article sur comment collecter des données légalement via des proxies.
Que faire si votre adresse figure dans ce dump
Il n'y a pas de mots de passe dans l'exportation, donc changer de mot de passe juste pour le fait d'être inclus n'a que peu de sens — mais le risque n'est pas nul, et il est spécifique.
- Vérifiez l'adresse sur Have I Been Pwned. L'entrée s'appelle Chess.com (2026), chargée le 13 septembre 2026, 4,6 millions d'adresses.
- Attendez-vous à du phishing ciblé. La combinaison « email + vrai nom + pays + classement + date de dernière connexion + statut d'abonnement » constitue un matériel prêt pour un email convaincant prétendument de la plateforme. Un envoi ordinaire ne ressemble pas à cela ; un email qui connaît votre classement, en revanche, semble crédible.
- Vérifiez où cette adresse a également été utilisée. 99 % des adresses avaient déjà été exposées dans des fuites précédentes — cela signifie que votre email est depuis longtemps dans des listes d'autres personnes et sera passé à travers la prochaine plateforme avec une fonction de recherche ouverte.
- Dissociez votre email de votre profil public là où c'est possible. Si le service permet d'interdire la recherche de soi par email ou téléphone — c'est exactement ce commutateur qui désactive ce vecteur pour vous personnellement.
Pour ceux qui construisent leur propre service, la conclusion de l'incident est encore plus simple : toute fonction qui répond « cet utilisateur existe, voici sa fiche » à partir d'un identifiant externe — c'est un index de recherche sur votre base, accessible de l'extérieur. Cela nécessite une limitation de rythme sur le compte et sur la sous-réseau IP, et pas seulement sur une seule adresse, plus une surveillance des échantillons lents et larges, qui apparaissent dans les métriques horaires comme un fond normal.
Le rôle des proxies — et ce qu'il n'est certainement pas
Il convient de le dire clairement, car après chaque incident de ce type, l'argument « tout cela se fait via des proxies » refait surface. Les proxies remplissent trois fonctions : réputation et ASN de l'adresse IP, géolocalisation de la requête, répartition de la charge pour ne pas dépasser la limite d'une adresse lors d'une collecte légale. Les proxies résidentiels sont nécessaires là où le site fournit un contenu différent selon la région ou bloque les sous-réseaux de centres de données, — par exemple lors de la surveillance des prix et des résultats dans différents pays.
Ce que les proxies ne font pas — ne transforment pas l'exploration d'emails d'autrui en collecte légale et ne protègent pas des conséquences. Dans le cas de Chess.com, la répartition par adresses a probablement permis de tirer des données pendant neuf jours sans être remarqué, mais c'est une caractéristique d'une protection faible de la plateforme, et non un argument en faveur d'un tel scénario. Techniquement, l'énumération n'est pas différente du trafic normal jusqu'à ce que quelqu'un mette en correspondance le volume avec les logs — et ensuite, la discussion ne porte pas sur les limites, mais sur le régulateur.
Conclusion
L'histoire de Chess.com est le troisième épisode en trois ans avec la même surface d'attaque et sans aucun piratage. Pour les plateformes, la conclusion est sévère : un contour de protection qui considère un incident comme une intrusion dans l'infrastructure ne voit pas comment la base est emportée par morceaux via une fonctionnalité standard. Pour ceux qui collectent des données de manière professionnelle, c'est aussi pratique : les restrictions se durcissent non à cause des parseurs de prix, mais à cause de telles histoires, et le coût de chaque nouvelle vague pèse sur l'ensemble de l'industrie de la collecte de données. Séparer la collecte publique et l'exploration d'identifiants personnels — ce n'est pas une question d'étiquette, c'est une question de savoir si les données publiques resteront accessibles.