One catalogued post says a consumer web platform lost its data in late 2025. Its narrative claims millions of rows, while its file summary, a few lines lower, provides a record count that is about fifty times smaller (DB-E008 in the evidence catalogue). The gap may reflect a difference of unit rather than a contradiction, but the post never says so.
A database leak post has two layers. The poster states a field list, a count, a year and an access condition, and the replies below then test some of those statements. Both layers tell a defender more than a headline count does.
Our pool is 1,124 claims, de-duplicated by post title (1,098 titles plus 26 posts without one). They are carried by 1,967 posts in three forum-oriented sets, collected between January and 27 October 2026. One AI reader read 100 template posts: 72 were a first-hand share, and the rest were replies, sale advertisements or not a share at all. Every figure below describes what posts say, not what happened.
A Count Means Nothing Without Its Sentence
A third of the claims (33%) give no count at all. Of all claims, 31% state a count in users, 16% in records, 5% in rows, 5% in lines and 1% in files. An additional 9% give an unqualified number such as “5M” with no unit of measurement. Among the 750 claims that do state a count, the magnitude varies enormously: 10% are under ten thousand and 19% are above ten million.
Units matter because they are not interchangeable. A compilation post in our catalogue provides a headline count, a deduplicated count about 14% lower and a file count about 24% lower (DB-E009). Another post provides two record counts that differ by about a factor of two (DB-E002). One reader of a different thread calculated that the unique email count sat about 2% below the stated user count (DB-E042).
For an organisation, the number closest to people is usually the unique one, which is the figure that posters mention least. A post that states “rows” may count lines in a log, and a post that states “records” may count one person several times. Without its sentence, a count cannot be reconciled with any record that you hold.
In Database Shares, Contact Data Outnumbers Passwords
The field lists consistently point in one direction, with email appearing in 62% of claims, name in 53%, physical address in 44% and phone in 41%. A password appears in 19%, date of birth in 16%, IP address in 11%, national ID in 6% and a payment card in 3%.
So in this pool, email is listed about three times as often as a password, and name, address and phone each appear more often than a password does. One in five claims (19%) lists five or more field categories, which could support targeted contact with the people concerned. An additional 23% list none of the nine categories we track; one three-line post gives only a title count and a link (DB-E012).
Where a password is listed, the post often does not say what kind. Of the 218 claims that mention one, 40% state hashed, 12% state plaintext and 47% give no type, and a named algorithm appears in 32%. Across all claims, that is about 8% stating hashed passwords and about 2% stating plaintext.
A stated field list can also contradict its own post. One lists emails and passwords formally, yet its own sentence says only a very small number of lines carry an email and a bcrypt hash (DB-E007). Another provides a field list, a named algorithm and a count in the millions, yet its 20-row sample contains short placeholder strings in the password column (DB-E014). A field list is what the poster asserts, not what the file actually contains.
The composition of the pool matters for this comparison, because it holds posts that share databases while credential lists sit elsewhere by design. Our stolen-credentials chapter covers combolists and account dumps, where passwords are the product, and the infostealer chapter covers the logs that often feed them.
The base rate does two jobs. It sets a prior for the posts that list none of the nine categories we track, nearly one in four. It also argues against defaulting to a credential playbook when a post is silent.
Testing the Old-Data-as-New Explanation
There is a competing interpretation of these posts: perhaps they recycle old breaches under fresh titles, so that an organisation wrongly believes the exposure is new. The most consequential finding bears on that interpretation directly. Of all claims, 45% state no obtained year, so for nearly half of them the post cannot establish for a reader whether the data is recent. Recirculation makes that gap matter.
One catalogued reply quotes an automated upload from 2023 about a breach that was already several years old. In 2026 it requests a repost because the link is dead (DB-E003). A second post separates the breach month from the month the data “circulated more widely” a few months later (DB-E010). A reader who sees only the later date would reasonably take the data for recent.
For the other claims, we could test the idea. Among the 614 that state a year (55% of the pool), counting back from 2026, 49% date the data to this year and 23% to the year before. An additional 16% state two to four years, 9% state five to nine and 3% state ten or more. In total, 172 claims (28%) are at least two years old, and 12% are at least five.
We sampled 45 of 173 distinct claim keys with at least one copy stating data two or more years old. The separate richest-copy age table contains 172 such claims. We read the opening text, approximately 650 characters, alongside the parsed fields.
In 41 of them the year appears within the first 400 characters, and three say the file is a re-upload; the 45 were chosen because a year was stated. We also scanned all 173 distinct claim keys for words such as “fresh”, “latest” and “new leak”, and five matched. On reading, all five were something else, such as a combolist advertisement or an unrelated recent event.
The opening-text and keyword checks found no older breach introduced with freshness wording. They do not establish what every full post said. About 4% of claims carry a re-upload marker. The test cannot be run for the 45% with no year, which is precisely the undated half in which an old file could pass for a new one.
Access Gates Shape the Thread
The access terms specify who can obtain the data. Of the claims, 29% give an open link, 29% are restricted behind a reply lock and 23% behind a credit or points lock. A further 10% use priced or sale wording, and 8% state no access condition at all.
That split depends on the unit of counting, since open links are 29% of claims, 38% of posts and 19% of opening posts. Our access classification was also only 90% accurate on a 40-post check, so treat it as a rough ordering, not as precise proportions.
Access gates also blur the distinction between sharing and selling. One post opens with the forum’s free-share greeting. It then says the thread is “for you to buy”, sets a single price and requests payment by direct message (DB-E013).
Reply locks may add short replies that quote the opening post, and 791 of the 1,967 posts are replies, so raw post counts overstate the number of claims. We did not test that mechanism. Our companion on how breach databases and lead lists are sold examines the terms of priced offers.
The Thread Does Some of the Checking
The replies contain information that the opening post lacks. We scanned 1,811 short forum replies across the fetched sets, and one AI reader read in full every reply that used wording about samples, earlier leaks, fakes or counts. Of the 106 hits, 73 (69%) were a reader challenging or testing a claim.
Allowing for challenges the wording missed, an estimated 5.5% to 13% of the replies do this, roughly 1 in 13 at the midpoint. The confirmed minimum is 4%.
The verification attempts are concrete, and some need only arithmetic:
- One reader recounted a file and found that about 6% of its lines were duplicate records (DB-E041).
- A second reader noted that the sample already held almost every record the sale offered (DB-E037).
- A third verified the email addresses against the service and found them already present in earlier lists (DB-E036).
- A fourth pointed out that a health file listed the patient name before the ID, while the sample showed the reverse (DB-E043).
Some of the signal is an echo. In one thread, at least ten near-identical short replies quote the same parent post (DB-E011), so the number of independent readers is smaller than the reply count. Readers also cite the forum’s own rule that a sale without a sample is assumed to be a scam (DB-E040).
For a defender, a thread can answer questions that the post cannot, and a reader’s remark that the data was already public elsewhere is an indicator on timing (DB-E035). A recalculation is a more reliable size estimate than the title. Each is one person’s statement rather than confirmation, but both are worth reading before a number is quoted in an internal report.
A Checksum Is Not a Password Hash
Many posts in this template carry a line with the archive’s own checksum next to the field list, and our first automated parse read that line as a password hash. It reported that 75% of password claims were hashed, whereas after correction the share is 40%. A “hashed passwords” line near a checksum may therefore describe the download file rather than the data inside it. The checksum itself says nothing about how passwords were stored.
Reading a Post Against Your Own Records
Four checks turn a post into a decision, and the first one decides the rest:
- Read the field list and sort the post into contact and identity data, credentials, or neither stated. That sorting decides which team needs it.
- Check which unit the count uses, and look for a unique-email figure. Rows and records can count one person several times.
- Check whether the post states a year. Without one, it cannot tell you the data is recent.
- Read the replies for a recount or a link to an earlier leak, since both change the size and age you should assume.
The response follows the field list. If the post lists contact and identity fields, which is the more frequent scenario, a password reset addresses little of that exposure. The risk sits closer to phishing, impersonation and support-desk pretexting against the people named, so customer-facing teams need the field list.
If a password is listed, treat its type as unknown unless the post names an algorithm, and test whether any credentials of yours are in scope. If no field is listed, do not borrow a playbook, and let the poster’s sentences and the thread establish what the post actually claims.
If the claim matches your records, the post-breach steps in our glossary apply. Our data leak detection page describes how such exposure is found in the first place.
Where the alert reached you as an automated card rather than a post, remember that the card reproduces a forum thread title and a constant “Data leak” tag. Our companion on relay cards and news retellings shows how to read those. For ongoing coverage of sources like these, see Brandefense dark web monitoring. The full evidence is in the data breach and leaks chapter.
Scope and Method
The pool holds share posts from three forum-oriented Blackhole sets, 1 January to 27 October 2026, reduced to 1,124 claims by post title, keeping the richest copy of each. Telegram, Discord and paste together account for 187 of the 1,967 posts (about 9.5%) and 13% of the claims. Another 322 posts (16%) are free shares or file drops, such as source code, account dumps or course files, so the pool is not only databases.
Forum post dates in Blackhole are partly day-and-month swapped, so we state period-level shares only and make no month-by-month statement. Counts are posts collected by Blackhole, not incidents, victims, sellers or transactions, and the data was not bought or tested. One AI reader (Claude) labelled the 100 template posts and the catalogue records, working separately from the parsing rules, with no second rater.
The first parser read field lists correctly in 63 of 100 posts. The corrected parser did so in 35 of 40 on a separate holdout (88%). Field shares therefore carry about three points of sampling error plus a few points of unknown classification bias. The reply-challenge range comes from a keyword scan of 1,811 replies plus a read of 100 non-hits.
Why AI agents. Brandefense Blackhole, our cybercrime database, collects around 17 to 23 million dark web and Telegram posts a month. Reading that volume by hand, and linking a recruitment ad on one forum to a leak-site claim on another and a price list in a Telegram channel weeks later, is beyond what a human team can do alone.
Claude Opus 5.5 prepared the research: it searched the data, sorted and translated posts and drafted the text. Codex Astra then checked every number against the dataset files and tested each claim, and anything that did not hold was removed.
Brandefense analysts reviewed and approved the findings.
