El 13 de septiembre de 2026, apareció en Have I Been Pwned un registro de Chess.com (2026): 7,3 millones de filas, 4,6 millones de direcciones de correo electrónico únicas. No hay contraseñas en el volcado, no hay hashes, no hay datos de pago. Y, al parecer, tampoco hubo una violación: los datos se recopilaron durante nueve días consecutivos mediante solicitudes normales al servicio en vivo. Este es el caso en el que "filtración" y "intrusión" son cosas diferentes, y vale la pena analizar la mecánica.
Qué exactamente se hizo público
El archivo apareció en un foro de cibercriminales el 12 de agosto de 2026 y se difundió a través de Telegram. El archivo descomprimido tiene 15,5 GB (744 MB en 7-Zip), con 7 337 395 registros de 38 campos cada uno.
- Direcciones de correo electrónico — aproximadamente el 75% de los registros (4,6 millones únicos).
- Nombres de usuario, nombres reales, ID de usuario y UUID.
- País, ubicación, idioma de la interfaz.
- Clasificaciones, títulos, nivel de juego, estado de la suscripción premium.
- Fechas de registro y último acceso — hasta agosto de 2026.
- Segmentos publicitarios de Google Ad Manager — campos gam_audiences y audiences_member_of.
El último punto es el más inesperado. Estas son etiquetas de marketing internas como "adecuado para el período de prueba", "usuario que se ha ido", rangos de clasificación, participación en experimentos con sugerencias de entrenadores. No son visibles para el usuario, no están en la API pública, no existe una configuración para "ver y corregir su segmento". Es decir, no solo se filtró el perfil, sino también cómo la plataforma misma etiqueta al jugador para la publicidad.
Por qué esto es scraping y no una violación: tres pruebas
Los analistas que examinaron el volcado se basaron no en las palabras del vendedor, sino en la estructura de los datos.
- Ritmo de recolección. Los registros están fechados en nueve días consecutivos — del 26 de julio al 3 de agosto de 2026, en lotes desiguales de 72 a 267 mil por día. La exportación simultánea de la base no se ve así: un volcado de un almacenamiento comprometido es un corte en un momento determinado.
- Duplicados. El 7,4% de los registros se repiten: la misma cuenta apareció en la exportación en diferentes días. Esto es un signo de un recorrido automatizado con una ventana deslizante, no de la exportación de una tabla.
- UUID de la primera versión. Los identificadores de Chess.com contienen una marca de tiempo incorporada. La verificación de la muestra mostró: 169 287 de 169 289 UUID coincidieron con la fecha de registro de la cuenta con una precisión de tres segundos. Falsificar tal correlación en millones de registros es imposible: los datos son reales, pero se obtuvieron mediante solicitudes legales.
En HIBP añadieron otro argumento: el 99% de las direcciones de correo electrónico del volcado ya habían aparecido en filtraciones anteriores. Para una base extraída directamente de producción, la proporción sería diferente — aquí se ve que las direcciones vinieron de afuera y se correlacionaron con las cuentas.
Mecánica: la función "encontrar amigos" como índice de búsqueda
El vector es conocido desde el incidente de 2023, cuando se filtraron primero 828 mil y luego alrededor de 476 mil registros de Chess.com con una estructura de campos idéntica. En ese momento, la empresa declaró claramente: "Esto NO es una filtración de datos. Nuestra infraestructura, cuentas y datos como contraseñas están seguros". Formalmente, es verdad.
El esquema es simple. La plataforma tiene una función de búsqueda de conocidos: subes una dirección de correo, el servicio responde si existe un usuario así y muestra su perfil. Tomamos una base de correos ajenos (hay miles de millones disponibles públicamente — de ahí esos 99% de coincidencias con filtraciones anteriores), la pasamos por esta función y obtenemos un perfil enriquecido: nombre, país, clasificación, fecha del último acceso, segmento publicitario.
Ninguna operación individual aquí parece un ataque. Se convierte en un ataque en millones de repeticiones. Los expertos que examinaron el volcado señalaron al culpable directamente: la subestimación de enumeration resistance, limitación de tasa y monitoreo de recolección lenta y amplia. Es decir, hay protección contra violaciones, pero no contra un sondeo paciente.
No es un caso aislado — es una clase de problemas
La demostración más grande de la misma clase es el estudio de la Universidad de Viena sobre WhatsApp. El equipo, a través de ingeniería inversa de la API de descubrimiento de contactos, consultó más de 100 millones de números de teléfono por hora, utilizando un servidor universitario y cinco cuentas autenticadas. El resultado — se enumeraron 3,5 mil millones de cuentas activas: números, fotos de perfiles, claves públicas. La limitación de tasa no funcionó ni una vez. El experimento se llevó a cabo desde diciembre de 2024 hasta abril de 2025, Meta cerró silenciosamente la brecha en octubre de 2025, y el trabajo se presentó en NDSS 2026.
Un detalle revelador del mismo estudio: el 58% de los números de teléfono de la antigua filtración de Facebook de 2021 seguían activos en WhatsApp. Los datos recopilados una vez no caducan — se convierten en material de entrada para la siguiente exploración. Chess.com en 2026 sufrió precisamente esto: fue atacado con una lista recopilada por alguien más y antes.
Qué cambia para quienes recopilan datos legalmente
Cada uno de estos incidentes golpea no al delincuente, sino a todos los que trabajan con datos públicos. La reacción de las plataformas es predecible: después de la divulgación, se endurecen los límites, se implementa el análisis de comportamiento, los endpoints de búsqueda y descubrimiento se ocultan detrás de la autorización y captcha. Tu cuidadoso parser de tarjetas de productos públicos no tiene relación con el sondeo de correos electrónicos — pero caerá bajo la nueva regla junto con todos los demás. Sobre los enfoques generales a este problema, hemos escrito en el análisis de limitaciones de API y cómo trabajar con ellas.
Por lo tanto, es importante mantener una clara frontera — no pasa por la técnica, sino por lo que haces con los identificadores de las personas.
- Datos públicos — lo que el servicio muestra a un visitante anónimo a través de un enlace directo: tarjeta de producto, precio, perfil público, publicación abierta. Recopilar — es normal.
- Enumeration — la inserción de una lista externa de correos, teléfonos o ID en una función de búsqueda para averiguar a quién pertenecen. Esto ya no es recopilación de datos públicos, sino correlación de identificadores personales, y en jurisdicciones con un régimen similar al GDPR se califica en consecuencia — independientemente de que el endpoint esté abierto.
- Campos ocultos. Los segmentos publicitarios de Chess.com no eran públicos de ninguna manera. Si la respuesta de la API trae algo que no está en la interfaz, no es un "bono", sino una señal para detenerse.
Una lista de verificación práctica para la recopilación ética: no inserte datos de contacto ajenos en funciones de búsqueda y descubrimiento; mantenga un ritmo que el servicio pueda soportar sin degradación; respete robots.txt y la oferta pública; recoja solo los campos visibles en la interfaz; no almacene información innecesaria. Hemos analizado la parte legal de la cuestión en detalle en el material sobre cómo recopilar datos legalmente a través de proxies.
Qué hacer si su dirección está en este volcado
No hay contraseñas en el volcado, por lo que cambiar la contraseña solo por el hecho de haber sido comprometido tiene poco sentido — pero el riesgo no es nulo, y es específico.
- Verifique la dirección en Have I Been Pwned. El registro se llama Chess.com (2026), se cargó el 13 de septiembre de 2026, 4,6 millones de direcciones.
- Espere phishing dirigido. La combinación "correo electrónico + nombre real + país + clasificación + fecha del último acceso + estado de suscripción" es material listo para un correo convincente supuestamente de la plataforma. Un envío normal no se ve así; un correo que conoce tu clasificación, sí.
- Verifique dónde más se ha utilizado esta dirección. El 99% de las direcciones ya habían aparecido en filtraciones anteriores — lo que significa que su correo electrónico ha estado en listas ajenas durante mucho tiempo y será procesado a través de la siguiente plataforma con una función de búsqueda abierta.
- Desvincule el correo de su perfil público donde sea posible. Si el servicio permite prohibir la búsqueda de uno mismo por correo electrónico o teléfono — ese es exactamente el interruptor que apaga el vector descrito personalmente para usted.
Para aquellos que construyen su propio servicio, la conclusión corta del incidente es aún más simple: cualquier función que responda "hay un usuario así, aquí está su tarjeta" por un identificador externo es un índice de búsqueda de su base, accesible desde afuera. Requiere limitación de tasa en la cuenta y en la subred IP, y no solo en una dirección, además de monitoreo de amplias selecciones lentas, que en métricas horarias parecen un fondo normal.
El papel de los proxies — y lo que definitivamente no son
Es importante decirlo claramente, porque después de cada uno de estos incidentes surge el argumento "todo esto se hace a través de proxies". Los proxies resuelven tres tareas: reputación y ASN de la dirección IP, geolocalización de la solicitud, distribución de carga para no superar el límite de una dirección con un volumen legal de recolección. Los proxies residenciales son necesarios donde el sitio entrega contenido diferente según la región o corta subredes de centros de datos, — por ejemplo, al monitorear precios y resultados en diferentes países.
Lo que los proxies no hacen — no convierten el sondeo de correos ajenos en una recopilación legal y no protegen contra las consecuencias. En el caso de Chess.com, la distribución entre direcciones probablemente permitió extraer datos durante nueve días sin ser detectado, pero esta es una característica de la débil protección de la plataforma, no un argumento a favor de tal escenario. Técnicamente, la enumeración no se diferencia del tráfico normal hasta el momento en que alguien correlaciona el volumen con los registros, — y ahí comienza la conversación no sobre límites, sino sobre el regulador.
Conclusión
La historia de Chess.com es el tercer episodio en tres años con la misma superficie de ataque y sin una sola violación. Para las plataformas, la conclusión es dura: el contorno de protección que considera un incidente solo la intrusión en la infraestructura no ve cómo la base se extrae por partes a través de una función estándar. Para aquellos que recopilan datos de manera profesional, también hay una conclusión práctica: las restricciones se endurecen no por parsers de precios, sino por historias como esta, y el costo de cada nueva ola recae sobre toda la industria de recopilación de datos. Separar la recopilación pública y el sondeo de identificadores personales — no se trata de etiqueta, se trata de si los datos públicos seguirán siendo accesibles en absoluto.