On September 13, 2026, a record for Chess.com (2026) appeared on Have I Been Pwned: 7.3 million rows, 4.6 million unique email addresses. There are no passwords in the dump, no hashes, and no payment data. And apparently, there was no breach either: the data was collected over nine consecutive days using standard queries to the live service. This is a case where "leak" and "breach" are different things, and it's important to understand the mechanics.
What Exactly Was Made Public
The archive appeared on a cybercriminal forum on August 12, 2026, and spread via Telegram. The unpacked file is 15.5 GB (744 MB in 7-Zip), containing 7,337,395 records with 38 fields each.
- Email addresses — present in about 75% of the records (4.6 million unique).
- Username, real names, user ID, and UUID.
- Country, location, interface language.
- Ratings, titles, skill level, premium subscription status.
- Registration and last login dates — up to August 2026.
- Google Ad Manager segments — fields gam_audiences and audiences_member_of.
The last point is the most unexpected. These are internal marketing tags like "suitable for trial period," "churned user," rating ranges, and participation in coach hint experiments. Users cannot see them, they are not available in the public API, and there is no setting to "view and correct your segment." This means that not only the profile was included in the dump, but also how the platform itself tags players for advertising.
Why This Is Scraping, Not Hacking: Three Pieces of Evidence
Analysts examining the dump relied not on the seller's words but on the data structure.
- Collection Rhythm. The records are dated over nine consecutive days — from July 26 to August 3, 2026, in uneven batches ranging from 72,000 to 267,000 per day. A one-time export of the database does not look like this: a dump from a compromised storage is a single snapshot at one moment.
- Duplicates. 7.4% of the records are repeated: the same account appeared in the export on different days. This indicates automated scraping with a sliding window, rather than a table export.
- First Version UUIDs. Chess.com identifiers contain a built-in timestamp. A sample check showed that 169,287 out of 169,289 UUIDs matched the account registration date within three seconds. Faking such correlation across millions of records is impossible — the data is real, but obtained through legally structured queries.
HIBP added another argument: 99% of the email addresses in the dump had already appeared in previous leaks. For a database lifted directly from production, the proportion would be different — here it is clear that the addresses came from outside and were matched with accounts.
Mechanics: The "Find Friends" Feature as a Search Index
The vector was already known from the 2023 incident when Chess.com first leaked 828,000 records, followed by about 476,000 more with an identical field structure. At that time, the company stated outright: "This is NOT a data leak. Our infrastructure, accounts, and data like passwords are safe." Formally, this is true.
The scheme is simple. The platform has a friend search feature: you upload an email address, the service responds whether such a user exists, and shows their profile. We take someone else's email database (there are billions available publicly — hence the 99% match with previous leaks), run it through this function, and get an enriched profile in return: name, country, rating, last login date, advertising segment.
No single operation here looks like an attack. It becomes an attack when repeated millions of times. Experts analyzing the dump named the culprit directly: underestimated enumeration resistance, rate limiting, and monitoring of slow wide scraping. This means there is protection against hacking, but not against patient enumeration.
This Is Not an Isolated Case — It Is a Class of Problems
The largest demonstration of the same class is the study by the University of Vienna on WhatsApp. The team, through reverse engineering of the contact discovery API, queried over 100 million phone numbers per hour using one university server and five authenticated accounts. The result — 3.5 billion active accounts were listed: numbers, profile pictures, public keys. Rate limiting did not work even once. The experiment ran from December 2024 to April 2025, and Meta quietly closed the loophole in October 2025, with the work presented at NDSS 2026.
A telling detail from the same study: 58% of phone numbers from the old Facebook leak of 2021 were still active on WhatsApp. Data collected once does not become outdated — it becomes input material for the next enumeration. Chess.com in 2026 suffered exactly from this: it was attacked with a list collected by someone else earlier.
What This Changes for Those Who Collect Data Legally
Each such incident hits not the perpetrator, but everyone who works with public data. The reaction of platforms is predictable: after the disclosure, limits are tightened, behavioral analysis is rolled out, search and discovery endpoints are hidden behind authentication and CAPTCHA. Your neat parser for public product cards is unrelated to email enumeration — but it will fall under the new rule along with everyone else. We discussed general approaches to this problem in our analysis of API rate limits and how to work with them.
Therefore, it is essential to maintain a clear boundary — it does not lie in the technique, but in what you do with people's identifiers.
- Public data — what the service shows to an anonymous visitor via a direct link: product card, price, public profile, open post. Collecting it is normal.
- Enumeration — substituting an external list of emails, phone numbers, or IDs into a search function to find out who they belong to. This is no longer collecting public data but matching personal identifiers, and in jurisdictions with GDPR-like regimes, it is qualified accordingly — regardless of whether the endpoint is open.
- Hidden fields. The advertising segments of Chess.com were not public in any form. If the API response includes something not visible in the interface, it is not a "bonus," but a signal to stop.
A practical checklist for conscientious data collection: do not substitute others' contact details into search and discovery functions; maintain a pace that the service can handle without degradation; respect robots.txt and the public offer; only collect fields visible in the interface; do not store unnecessary data. We explored the legal side of the issue in detail in our material on how to collect data legally through proxies.
What to Do If Your Address Is in This Dump
There are no passwords in the dump, so changing your password just because it was included makes little sense — but the risk is not zero, and it is specific.
- Check your address on Have I Been Pwned. The record is called Chess.com (2026), uploaded on September 13, 2026, with 4.6 million addresses.
- Expect targeted phishing. The combination of "email + real name + country + rating + last login date + subscription status" is ready material for a convincing email supposedly from the platform. A typical newsletter does not look like this; an email that knows your rating does.
- Check where else this address has been used. 99% of addresses have already appeared in previous leaks — meaning your email has long been in someone else's lists and will be run through the next platform with an open search function.
- Unlink your email from your public profile where possible. If the service allows you to prevent being searched by email or phone — that is precisely the switch that disables the described vector for you personally.
For those building their own service, the short takeaway from the incident is even simpler: any function that responds "such a user exists, here is their profile" based on an external identifier is a search index of your database accessible from the outside. It requires rate limiting on accounts and IP subnets, not just on one address, plus monitoring of wide slow extractions that appear as normal background in hourly metrics.
The Role of Proxies — and What They Are Definitely Not
It should be stated clearly, because after each such incident, the thesis "all this is done through proxies" resurfaces. Proxies solve three tasks: reputation and ASN of the IP address, geographical binding of the request, load distribution to avoid exceeding the limit of one address during legal data collection. Residential proxies are needed where the site delivers different content by region or cuts data center subnets — for example, when monitoring prices and search results in different countries.
What proxies do not do — they do not turn the enumeration of someone else's emails into legal data collection and do not protect against consequences. In the Chess.com case, distribution across addresses likely allowed data to be pulled for nine days unnoticed, but this is a characteristic of weak platform protection, not an argument in favor of such a scenario. Technically, enumeration is indistinguishable from normal traffic until someone correlates the volume with logs — and then the discussion shifts from limits to regulators.
Conclusion
The Chess.com story is the third episode in three years with the same attack surface and no actual breach. For platforms, the takeaway is harsh: a protection framework that considers an incident only a breach of infrastructure does not see how the database is extracted piece by piece through a standard feature. For those who collect data professionally, the practical takeaway is also clear: restrictions are tightened not because of price parsers, but because of such stories, and the cost of each new wave falls on the entire data collection industry. Distinguishing between public collection and enumeration of personal identifiers is not about etiquette; it is about whether public data will remain accessible at all.