On September 7, 2026, a database of 32,815,767 Condé Nast user records went up for sale on a Russian-language cybercrime forum. Asking price: $15,000.
That works out to roughly $0.00046 per record.
No passwords. No hashes. No payment card numbers. The technically accurate summary is "no credentials were exposed" — and if you stop reading there, you will file this as a minor event.
I am not going to argue about whether it matters (it does, but that is a different post). What I want to talk about is the part that is actually reusable: how do you know a breach dump is real?
Because most of them are not. Listings get advertised constantly, and a large fraction are recycled, padded, or invented outright. Ransomnews did the thing that separates verification from retweeting: it took the seller's free 5,000-row sample and ran internal consistency tests on it, deliberately without attempting to log into any live Condé Nast account.
Here are the four tests. They are the same ones you should mentally apply to the next breach headline you see.
Test 1: Field completion vs. claims
The seller advertised fill rates for the full dataset. The sample's actual fill rates came within 1.2 percentage points of those claims.
This is a weak signal on its own — anyone generating fake data can hit a target fill rate — but it is a cheap first filter, and a surprising number of listings fail it.
Test 2: Name-to-email correlation, with a control group
This is the one I actually like.
Among records with a full name, 61.9% used an email address matching that name or its initials. Fine. But a single number like that means nothing without something to compare it against.
So Ransomnews randomly shuffled names between records and re-ran the same check. The match rate collapsed to 0.3%.
That is the whole test. Fabricated or assembled data does not survive a control group, because there is no underlying relationship to destroy. Shuffling a real dataset breaks a real correlation; shuffling a synthetic one changes nothing, because there was never anything there to begin with.
If you take one thing from this post, take the control group.
Test 3: Nothing predates its own email provider
Of the 227 records using Apple Relay, iCloud, Outlook, Me.com, or Proton addresses, none had an account creation date earlier than the service existed.
This catches a specific and common failure mode: datasets assembled by scraping and merging, where the generator pulls a signup date from one pool and an email domain from another, without checking whether the two could coexist.
Test 4: Geography holds together
- 96.4% of US ZIP codes matched the listed state
- 93.5% matched the listed city
Again, this only works as a check because ZIP-to-place is a real external constraint that the data-generating process did not know about.
My favourite detail: the messiness
The file contains placeholder text like "Select your state". Numeric dropdown values where a country name should be. Inconsistent country labels. Lower-case names. A pile of birth dates set to 1 January.
Generated data is clean. Data that accumulated through decades of web forms is embarrassing — and this file is embarrassing in exactly the right ways.
I would argue this is the most under-rated authenticity signal in breach analysis. Everyone looks for internal consistency. Fewer people check whether the data looks like it was produced by real software used by real humans, artifacts and all.
What is actually in it
Every record has an email. Coverage drops off fast after that:
| Field | Coverage |
|---|---|
| First + last name | 31.6% |
| Postal address | 22.3% |
| Gender | 17.5% |
| Date of birth | 12.6% |
| Phone number | 2.9% |
Read this as a filtering problem, not a completeness problem. A buyer does not need every field on every row. They need the roughly 12.6% of records carrying a date of birth, cross-referenced against the 22.3% with an address, intersected with data from the next breach. Name plus address plus date of birth is enough to attempt synthetic identity construction, and to get past knowledge-based authentication at institutions that still rely on it.
And the email addresses alone are credential-stuffing fuel. Condé Nast did not leak a single password, but a list of 32.8 million confirmed-active consumer inboxes is exactly the input to an automated campaign against every other site those people use.
The arithmetic that links it to WIRED
In December 2025, an actor using the name "Lovely" published 2,366,576 WIRED subscriber records and claimed to have taken more than 40 million Condé Nast records overall.
The new listing also offers a WIRED-removed variant containing 30,455,594 records.
32,815,767 − 30,455,594 = 2,360,173
Against the December figure of 2,366,576. The arithmetic lines up neatly enough to link the two events — though it does not prove the current seller is the original intruder. They could be a partner, or someone who bought the data secondhand.
The new sample is also not simply a re-upload of the public WIRED data. It has a different field structure, higher rates of names and street addresses, and a demographic distribution consistent with Condé Nast's broader consumer titles rather than WIRED specifically. Account creation dates run from February 1999 to 23 October 2025, thinning sharply after September, which points to an extraction window between September and late October 2025.
One honest limit
32.8 million is the seller's claimed row count. Nobody has verified all of it. The sample is genuine; the total is not independently confirmed.
Hold both of those at once. It is the correct epistemic position, and almost nobody reports it that way.
The company has not said anything
Condé Nast has not publicly confirmed the breach, commented on the sale, or issued any statement since the December 2025 WIRED leak. Ransomnews contacted the company asking whether the flaws "Lovely" described were ever closed, and whether readers outside WIRED were ever notified. There has been no response.
That silence is harder to sustain than it used to be. Vogue and GQ have large European readerships, and GDPR Article 33 requires notifying a supervisory authority within 72 hours of becoming aware of a breach. Whether any of that was triggered depends on facts only the company has.
One clarification that keeps getting muddled: Ars Technica is owned by Condé Nast but runs on separate systems, and has said it was unaffected.
The four tests — claimed-vs-actual fill rates, correlation with a shuffled control, impossible-before-launch timestamps, and external geographic consistency — are worth keeping in your head. They cost almost nothing to apply, and they turn "someone posted a file" into an actual finding.
If you work with breach data or incident response: what is your first check? I am curious whether the control-group test is as under-used outside this space as I think it is.
Full breakdown, including what to actually do if you are in the file: cyberpicks.org
Originally published at CyberPicks.
Top comments (0)