13 de setembro de 2026, uma entrada apareceu no Have I Been Pwned referente a Chess.com (2026): 7,3 milhões de registros, 4,6 milhões de endereços de email únicos. Não há senhas no dump, não há hashes, não há dados de pagamento. E, aparentemente, também não houve invasão: os dados foram coletados durante nove dias consecutivos por meio de solicitações normais ao serviço ativo. Este é um caso em que "vazamento" e "invasão" são coisas diferentes, e é importante entender a mecânica.
O que exatamente foi exposto publicamente
O arquivo apareceu em um fórum de cibercrime em 12 de agosto de 2026 e se espalhou pelo Telegram. O arquivo descompactado tem 15,5 GB (744 MB em 7-Zip), contendo 7.337.395 registros com 38 campos cada.
- Endereços de email — aproximadamente 75% dos registros (4,6 milhões únicos).
- Nomes de usuário, nomes reais, ID de usuário e UUID.
- País, localização, idioma da interface.
- Avaliações, títulos, nível de jogo, status da assinatura premium.
- Datas de registro e último login — até agosto de 2026.
- Segmentos publicitários do Google Ad Manager — campos gam_audiences e audiences_member_of.
O último item é o mais inesperado. Estas são etiquetas de marketing internas como "adequado para período de teste", "usuário que saiu", intervalos de classificação, participação em experimentos com dicas de treinador. Os usuários não podem vê-las, não estão disponíveis na API pública, e não existe a configuração "ver e corrigir seu segmento". Ou seja, não apenas o perfil foi exposto, mas também como a plataforma classifica o jogador para publicidade.
Por que isso é scraping e não invasão: três provas
Os analistas que examinaram o dump basearam-se não nas palavras do vendedor, mas na estrutura dos dados.
- Ritmo de coleta. Os registros datam de nove dias consecutivos — de 26 de julho a 3 de agosto de 2026, em lotes irregulares de 72 a 267 mil por dia. A exportação única da base não se parece assim: um dump de um armazenamento comprometido é um único corte em um único momento.
- Duplicatas. 7,4% dos registros se repetem: a mesma conta aparecia na exportação em dias diferentes. Isso é um sinal de um processo automatizado com uma janela deslizante, e não uma exportação de tabela.
- UUID da primeira versão. Os identificadores do Chess.com contêm um timestamp embutido. A verificação da amostra mostrou: 169.287 de 169.289 UUIDs coincidiram com a data de registro da conta com precisão de até três segundos. Falsificar tal correlação em milhões de registros é impossível — os dados são reais, mas obtidos por solicitações legais.
No HIBP, foi adicionado mais um argumento: 99% dos endereços de email no dump já apareceram em vazamentos anteriores. Para uma base extraída diretamente da produção, a proporção seria diferente — aqui, é evidente que os endereços vieram de fora e foram mapeados com as contas.
Mecânica: a função "encontrar amigos" como índice de busca
O vetor é conhecido desde o incidente de 2023, quando o Chess.com vazou inicialmente 828 mil e depois mais cerca de 476 mil registros com a mesma estrutura de campos. Naquela ocasião, a empresa afirmou claramente: "Isso NÃO é um vazamento de dados. Nossa infraestrutura, contas e dados como senhas estão seguros". Formalmente, isso é verdade.
A mecânica é simples. A plataforma possui uma função de busca de conhecidos: você carrega um endereço de email, o serviço responde se tal usuário existe e mostra seu perfil. Pegamos uma base externa de emails (existem bilhões disponíveis publicamente — daí os 99% de coincidências com vazamentos anteriores), passamos por essa função e obtemos um perfil enriquecido: nome, país, classificação, data do último login, segmento publicitário.
Nenhuma operação isolada aqui parece um ataque. Isso se torna um ataque em milhões de repetições. Especialistas que analisaram o dump identificaram o culpado diretamente: a subestimada resistência à enumeração, limitação de taxa e monitoramento de coleta ampla e lenta. Ou seja, há proteção contra invasão, mas não contra tentativas persistentes.
Isso não é um caso isolado — é uma classe de problemas
A maior demonstração da mesma classe é o estudo da Universidade de Viena sobre o WhatsApp. A equipe, através de engenharia reversa da API de descoberta de contatos, consultou mais de 100 milhões de números de telefone por hora, usando um servidor universitário e cinco contas autenticadas. O resultado — listados 3,5 bilhões de contas ativas: números, fotos de perfil, chaves públicas. A limitação de taxa não funcionou uma única vez. O experimento ocorreu de dezembro de 2024 a abril de 2025, a Meta silenciosamente fechou a brecha em outubro de 2025, e o trabalho foi apresentado na NDSS 2026.
Um detalhe revelador do mesmo estudo: 58% dos números de telefone do antigo vazamento do Facebook de 2021 ainda estavam ativos no WhatsApp. Dados coletados uma vez não se tornam obsoletos — eles se tornam material de entrada para a próxima tentativa. O Chess.com em 2026 sofreu exatamente isso: foi atacado com uma lista coletada por outra pessoa anteriormente.
O que isso muda para quem coleta dados legalmente
Cada um desses incidentes atinge não o criminoso, mas todos que trabalham com dados públicos. A reação das plataformas é previsível: após a divulgação, os limites são apertados, análises comportamentais são implementadas, e os endpoints de busca e descoberta são ocultados atrás de autenticação e captcha. Seu cuidadoso parser de cartões de produtos públicos não tem relação com a enumeração de emails — mas será afetado pelas novas regras junto com todos os outros. Sobre as abordagens gerais a esse problema, escrevemos na análise de limites de API e como lidar com eles.
Portanto, é importante manter uma linha clara — ela não passa pela técnica, mas pelo que você faz com os identificadores das pessoas.
- Dados públicos — aquilo que o serviço mostra a um visitante anônimo através de um link direto: cartão de produto, preço, perfil público, postagem aberta. Coletar é normal.
- Enumeração — inserção de uma lista externa de emails, telefones ou IDs em uma função de busca para descobrir a quem pertencem. Isso já não é coleta de dados públicos, mas mapeamento de identificadores pessoais, e em jurisdições com regimes semelhantes ao GDPR, é qualificado de acordo — independentemente de o endpoint estar aberto.
- Campos ocultos. Os segmentos publicitários do Chess.com não eram públicos de forma alguma. Se a resposta da API contém algo que não está na interface, isso não é um "bônus", mas um sinal para parar.
Uma lista de verificação prática para coleta de dados de boa-fé: não insira dados de contato de terceiros em funções de busca e descoberta; mantenha um ritmo que o serviço suporte sem degradação; respeite o robots.txt e a oferta pública; colete apenas os campos visíveis na interface; não armazene dados desnecessários. A parte legal da questão foi discutida em detalhes no material sobre como coletar dados legalmente através de proxies.
O que fazer se seu endereço estiver neste dump
Não há senhas no dump, portanto, mudar a senha apenas pelo fato de estar exposto não faz muito sentido — mas o risco não é nulo, e é específico.
- Verifique o endereço no Have I Been Pwned. O registro é chamado Chess.com (2026), carregado em 13 de setembro de 2026, 4,6 milhões de endereços.
- Aguarde phishing direcionado. A combinação "email + nome real + país + classificação + data do último login + status da assinatura" é material pronto para um e-mail convincente supostamente da plataforma. Um envio comum não se parece assim; um e-mail que conhece sua classificação, sim.
- Verifique onde mais esse endereço foi usado. 99% dos endereços já apareceram em vazamentos anteriores — isso significa que seu email já está em listas de terceiros e será passado pela próxima plataforma com função de busca aberta.
- Desvincule o email do perfil público onde for possível. Se o serviço permite proibir a busca por você por email ou telefone — esse é exatamente o interruptor que desativa o vetor descrito pessoalmente para você.
Para aqueles que estão construindo seu próprio serviço, a conclusão a partir do incidente é ainda mais simples: qualquer função que responda "esse usuário existe, aqui está seu cartão" com base em um identificador externo é um índice de busca em sua base, acessível externamente. Isso requer limitação de taxa por conta e por sub-rede IP, e não apenas por um único endereço, além de monitoramento de amostras amplas e lentas, que em métricas horárias parecem um fundo normal.
O papel dos proxies — e o que definitivamente não é
É importante dizer claramente, porque após cada um desses incidentes surge a tese "tudo isso é feito através de proxies". Proxies resolvem três tarefas: reputação e ASN do endereço IP, vinculação geográfica da solicitação, distribuição de carga para não exceder o limite de um único endereço durante uma coleta legal. Proxies residenciais são necessários onde o site fornece conteúdo diferente por região ou corta sub-redes de data centers — por exemplo, ao monitorar preços e resultados em diferentes países.
O que os proxies não fazem — não transformam a enumeração de emails de terceiros em coleta legal e não protegem contra consequências. No caso do Chess.com, a distribuição entre endereços, provavelmente, permitiu puxar dados por nove dias sem ser notado, mas isso é uma característica de proteção fraca da plataforma, e não um argumento a favor desse cenário. Tecnicamente, a enumeração é indistinguível do tráfego normal até o momento em que alguém compara o volume com os logs — e então a conversa não é sobre limites, mas sobre reguladores.
Conclusão
A história do Chess.com é o terceiro episódio em três anos com a mesma superfície de ataque e sem uma única invasão. Para as plataformas, a conclusão é dura: um contorno de proteção que considera um incidente apenas como uma invasão na infraestrutura não percebe como a base é retirada em partes através de uma funcionalidade padrão. Para aqueles que coletam dados profissionalmente, a conclusão também é prática: as restrições são endurecidas não por causa de parsers de preços, mas por causa de histórias como essa, e o custo de cada nova onda recai sobre toda a indústria de coleta de dados. Separar a coleta pública e a enumeração de identificadores pessoais — não é uma questão de etiqueta, é sobre se os dados públicos permanecerão acessíveis.