Most data-leak listings on criminal forums are not what they claim to be. Some are fabricated outright, some are genuine but years old, some are scraped from public profiles rather than breached, and some are real data whose owner is not the company named in the headline. The verification desk tests the sample before we write a word, publishes the tests alongside the verdict, and contacts the organisation and the regulator before publication. This page collects the verdicts, explains the method, and tells you how to send us a listing.
Verdicts
Newest first. Each verdict links to the full analysis, including what we did not do: we never authenticate against a live service, never buy a data set, and never publish personal data.
| Date | Listing | Verdict | The tell |
|---|---|---|---|
| 3 Sep 2026 | The Town 2025 ticket data, sold as a Ticketmaster breach | Genuine data, custodian unconfirmed | Purchase IDs ascend perfectly with purchase date and every CPF validates, but every row carries the same export timestamp two weeks after the festival, which points to a shared post-event manifest rather than a live database. |
| 28 Aug 2026 | Love Electric driver records, 877,000 claimed | Genuine sample, scale unverified | DVLA licence numbers decode to the names and birth dates on the same rows, employer email domains and postcodes agree, and the schema has the ragged nulls of a real production export. |
| 18 Aug 2026 | Live Stripe API keys for 659 merchants | Genuine keys, not a Stripe breach | Object identifiers, live-mode session prefixes and card field sets match real API output; the keys were pulled from the merchants’ own systems. Stripe was told before publication. |
| 16 Aug 2026 | McDonald’s employee data, 1.7 million claimed | Genuine sample, scale unverified | All 50 email domains in the sample are McDonald’s-controlled, including the tenant’s built-in onmicrosoft.com address, and the encoding damage matches a PowerShell export from Entra ID. |
| 12 Aug 2026 | 7.3 million chess.com records | Genuine, but scraped rather than breached | 169,287 of 169,289 version-1 UUIDs carry a creation timestamp matching the account’s join date to the second, and capture dates run in daily batches, the signature of an incremental harvest. |
| 10 Aug 2026 | Pokémon Center vending “breach” across 28 brands | Genuine, but ten years old | Product catalogues carry valid UPCs, but all 200 embedded timestamps decode to late 2016 and 91% of the emails are SMTP relay addresses, not customers. |
| 10 Aug 2026 | Israel population registry, 9.22 million claimed as current | Genuine, but a 2005 snapshot | All but three of 100,000 national ID numbers pass the check-digit test and household links resolve, but every date field stops in 2005, matching the long-circulated Agron dump. |
| 3 Aug 2026 | Żabka source code and data, listed at €5,000 | Genuine, confirmed by the company | Project totals, repository counts and a reused GitLab token were internally consistent; Żabka confirmed unauthorised access through a supplier account. |
Not every listing we test is published. Two large dating-app data sets offered in August 2026 failed the tests below in ways that pointed to generation rather than theft, and we chose not to amplify them. A verdict of “fabricated” is still a verdict, and we will say so when the listing has already spread widely enough that silence would mislead.
The verdict scale
- Genuine, confirmed. The organisation named has acknowledged an incident consistent with the listing.
- Genuine sample, scale unverified. The published sample passes every test we can apply, but the seller’s headline record count is their claim, not ours.
- Genuine data, custodian unconfirmed. The data is real, but the evidence does not establish which organisation lost it. Ticketing manifests, supplier exports and partner feeds all fall here.
- Genuine, but old. Real records recycled from an earlier breach and re-marketed as new. The embedded dates give it away.
- Genuine, but scraped. Real records harvested from public profiles or an open API rather than taken from inside a company.
- Fabricated. Generated data. Too tidy, internally inconsistent, or built from a public test-data library.
How we test a sample
Every test runs offline against the free sample the seller publishes. We do not log in anywhere, we do not query any live service with the data, and we do not buy anything. The tests are chosen because generated data fails them in characteristic ways and real data passes them without trying.
- Identifier check digits. National ID numbers (CPF, Israeli ID, NI numbers), driving licence encodings, UPCs and card BINs all carry internal checksums. A file that fails them is fake; a file that passes has cleared a necessary but not sufficient bar, because every test-data library implements the same algorithms.
- Sequence order. Database primary keys increase with time. When records sorted by date show identifiers in strictly ascending order, that is an auto-increment key at work; random identifiers falling into date order across a dozen records is a one-in-billions event.
- Timestamp agreement. Epoch timestamps must decode to the human-readable dates beside them, and version-1 UUIDs, Firebase push IDs and similar identifiers carry their own creation time, which must agree with the record’s stated dates. This is also how recycled dumps are caught: the embedded dates stop years ago.
- Geography. Telephone area codes must match the recorded state or region, neighbourhoods must belong to their cities, and postcodes must sit where the addresses say. Generators default to capital cities; real customers live in Sorocaba.
- Price and business logic. Half-price tickets cost exactly half. Instalment counts fit the card brand. Tax IDs match the entity type. Real systems enforce these rules; fabricated files rarely bother.
- Distribution realism. Real dumps carry the email providers of the population (icloud, outlook, national ISPs), not just gmail and yahoo. Real free-text fields repeat rarely; generated ones reuse a small vocabulary.
- Raggedness. Real exports have nulls where the business process left gaps, such as complimentary tickets with no buyer or accounts that never set a phone number. Fabricated sets are uniformly populated.
- Internal arithmetic. The seller’s own breakdowns should reconcile: country counts against totals, age bands against country counts, file sizes against row counts.
Passing the tests tells us the data is real. It does not tell us who lost it, and that distinction runs through every verdict above. The longer version of the method, written for newsrooms and researchers, is How to verify a leaked dataset before you write about it, and the leak-site side of the work is in the leak-site investigation walkthrough.
What we do before publishing
Once a sample passes, we write to the organisation named in the listing, to any other organisation the evidence points at, and to the relevant data-protection authority, before the article goes live. The email sets out the tests, offers the listing and the sample to their incident responders at no cost, and asks four questions: is the data yours, are you aware of an incident, has the regulator been told, and is anything in our assessment wrong. Responses are published in full. The article says who was contacted and when, and is updated when they answer. Screenshots are watermarked and redacted; sample rows are masked field by field and never reproduced in full; seller handles, download locations and contact details are not published.
Send us a listing
If you have seen a listing that names your organisation, your customers or your country, or you are a journalist who wants a sample tested before you report it, write to [email protected] with the forum, the seller handle and, if you have it, the sample. We do not need the full data set and would rather not receive it. We answer quickly, we credit tips only with permission, and we correct the record when someone shows us we are wrong. Individuals who want to know whether their own credentials are circulating can use the free Stealercheck lookup.
Frequently asked questions
How can you tell whether a data breach is real?
Test the sample rather than the claim. Real records carry identifiers with valid check digits, primary keys that rise with time, timestamps that agree with each other, geography that fits, business rules that hold, and the ragged gaps of a real process. Generated data fails several of these at once; recycled data passes them but its embedded dates stop years ago.
Does a genuine sample mean the named company was breached?
No. It means the data is real. Who lost it is a separate question, and the evidence often points elsewhere: a supplier, a promoter, a partner that received an export. That is why our verdicts distinguish “genuine” from “custodian unconfirmed”, and why we contact every organisation the evidence implicates.
Why do sellers fabricate leaks?
Because forum reputation and escrow deposits are cheap and a headline is valuable. A fabricated “breach” of a well-known brand attracts buyers, press attention and sometimes a payment from a company that would rather not find out the hard way. Recycled data works the same way with less effort.
Do you buy data to verify it?
Never. We test only the free sample the seller has already published, offline, and we do not authenticate against any live service with it. Buying data funds the trade and is often illegal.
Will you publish my data if it appears in a leak?
No. Screenshots are redacted and watermarked, sample rows are masked field by field, and no individual record is reproduced in full. We publish what proves the verdict, not the data itself.
How do I find out if I am in a leak?
For the listings above, the linked article says what was exposed and what to do. For credentials and session cookies stolen by infostealers, which is a different exposure route that affects the same people, the free Stealercheck lookup covers any domain.