The 340 Million OnlyFans "Leak" That Wasn't: How Hackers Repackage Old Breaches as New Ones

On May 24, 2026, a post appeared on a well-known cybercrime forum offering 340 million records, allegedly stolen from inside OnlyFans, for 0.313 BTC (roughly $76,000). Within hours the story was viral on X. Screenshots of the listing were shared millions of times. News outlets reported on it. The dataset supposedly contained emails, phone numbers, usernames, partial payment card data, profile metrics, and linked social media accounts for the platform's 380 million users.

Then a few uncomfortable things happened. OnlyFans denied any breach. Have I Been Pwned founder Troy Hunt publicly questioned the technical details. Hackread contacted the seller directly via Telegram, and the seller admitted, in plain language, that the database was not pulled from OnlyFans at all. It was built from existing breach datasets and public profile data, cross-referenced and repackaged as something new.

This is a story about a fake breach. It is also a story about one of the most successful techniques in modern cybercrime: data enrichment attacks. Even though the OnlyFans claim collapsed under scrutiny, the methodology behind it is real, it is widely used, and it is responsible for a surprising amount of the "new" breaches you read about in any given month.

Here is what actually happened, why it worked as a viral hoax for several days, and how the underlying technique is reshaping how stolen data gets weaponized in 2026.

What the listing claimed

The post on the leak forum, attributed to a seller using the alias "Euphoric_Reply_5727," promised the following for each of the 340 million alleged records:

• Username and profile display name
• Email address
• Phone number
• Last four digits of a payment card
• Profile activity metrics (followers, content counts, engagement)
• Linked external social media accounts (Twitter/X, Instagram, Spotify)

The pitch was tailored to maximize shock. For most services, leaked email and phone data is bad but recoverable. For OnlyFans, the linked-social-account field is the dangerous part. The entire value proposition of the platform for many users (both creators and subscribers) is anonymity. Linking an anonymous OnlyFans username to a real Instagram or Twitter account effectively doxxes the user, sometimes catastrophically. That is what made the story go viral. The implication was that millions of people were about to be exposed.

The price (about $76,000 in cryptocurrency) was deliberately positioned to look serious but accessible. Real high-value breach data often sells for hundreds of thousands of dollars. A $76,000 price tag for 340 million records signaled "this is real, but the seller wants quick liquidity." That framing convinced a lot of people on social media that the breach was authentic.

Why this probably isn't a real breach

Within 48 hours of the listing going up, multiple security researchers had picked it apart. Troy Hunt, who runs Have I Been Pwned and has analyzed more genuine breaches than almost anyone alive, posted publicly that the "scrape" explanation did not align with the data types being advertised. His specific objection: real backend database dumps look like database dumps. The OnlyFans listing showed fields like streams_count and likes_count, which resemble frontend API attributes returned to a logged-in user, not the column names you would see in an actual breached database.

That is the kind of technical detail that gives the game away. When attackers actually compromise a service, they dump the database. The field names you get are the field names the developers used internally, with all the ugly inconsistencies and legacy quirks that come with real production code. What was being advertised here looked too clean, too API-shaped, too much like data that had been pulled together from outside the system rather than extracted from inside it.

Cybernews also noted that sample records appeared to date from around August 2025, almost a year old by the time of the listing. Genuine recent breaches are usually marketed with recent timestamps. Stale dates are a tell that the data is not fresh.

OnlyFans formally denied any breach. Validation tests performed by Hackread on a sample of email addresses did not produce the expected "this email is already registered" warnings you would get from a real internal user list. By the time the seller went on Telegram and admitted the dataset was assembled from other sources, the "breach" story had already lost most of its credibility among researchers, even though it was still trending on X.

What it actually is: a data enrichment attack

Here is where the story gets interesting for everyone, not just OnlyFans users. The technique the seller used to assemble this "breach" is genuinely powerful, and it is being used right now against thousands of platforms beyond OnlyFans.

A data enrichment attack works like this. The attacker starts with a base dataset, typically a real password breach from somewhere else. Then they layer additional information on top by matching identifiers across multiple sources. Email addresses are the universal connector. If you have an email from an old breach, you can search for that email across:

• Other breach databases (Collection #1, RockYou2024, naz.api, hundreds of smaller ones)
• Public social media profiles indexed by search engines or scraped via APIs
• People-search sites (Spokeo, BeenVerified, public phone directories)
• LinkedIn scrapes (the 2021 700-million-record one is still circulating)
• Voter rolls and other public records
• Forum profiles linked to that email
• Compromised credentials marketplaces

Match enough sources and you end up with a richer profile of each person than any single breach would have produced. You can then market the resulting database as if it came from one place, when in reality it is a compilation that was never inside any single victim's systems.

That is what the OnlyFans seller did. They started with a list of email addresses that appeared somewhere in their existing leak collections, filtered for any account that could plausibly be linked to OnlyFans (likely by checking if the email had ever interacted with the domain, or by buying that interaction data separately), and then enriched each match with whatever public-source data they could find. The resulting dataset has the shape of a breach without ever requiring an actual breach.

How attackers build "mega-leaks" from scratch

The mechanics are not particularly sophisticated, which is part of what makes the technique scalable. A small team or even a single skilled operator can put one of these together over a few weeks.

Step one: acquire the base data. This is the cheap part. Collection #1, the famous 2019 mega-compilation, contains 773 million unique emails and 21 million unique passwords. It is freely available. RockYou2024, leaked in July 2024, added another 10 billion passwords. The naz.api collection has over a billion credential pairs. Combined, these public-domain compilations cover most of the active internet.

Step two: filter for the angle. If the attacker wants to sell a "Spotify breach," they filter the base data for any email that has ever interacted with Spotify in some traceable way. If they want a "Tinder breach," same process for Tinder. If they want OnlyFans, they look for emails that appeared in any older OnlyFans-adjacent leak (small forum dumps, OF subscriber list scrapes, content-piracy site databases, leaked Patreon-OnlyFans cross-reference data, etc.). None of this requires breaching the target platform itself.

Step three: enrich. For each email that survives the filter, the attacker pulls additional fields from other sources. Social media APIs (public profile data is free), people-search sites (cheap, sometimes free), credit header data (sold by various legal and gray-market vendors), other breach databases. Each pass adds more fields per record. After enough passes, you have a dataset that looks remarkably complete.

Step four: fill in the gaps. If certain fields are missing for too many records, attackers sometimes just generate plausible-looking values. For technical fields like timestamps, they pick values consistent with the rest of the data. For some categories of leaks, AI-generated synthetic data is increasingly common. The IntCyberDigest account on X suggested some of the OnlyFans data may have been AI-generated, though that has not been confirmed.

Step five: market. The dataset gets a name, a backstory, and a price. Marketing matters more than the data itself at this point. A "300+ million record OnlyFans breach" attracts buyers and resellers, even if half the records are recycled and the other half are fabricated. Once a few buyers exist, the dataset starts moving through underground markets, getting renamed and rebundled, and eventually shows up as "evidence" of a breach that may never have happened.

Why this matters even when the "breach" is fake

It is tempting to look at the OnlyFans story and conclude that since it was fake, nobody got hurt. That misses the point in three ways.

First, the underlying data is still real for many of the listed users. Even if 60% of the "OnlyFans breach" records are recycled junk, the 40% that are accurate represent real people whose emails and account associations are now linked together in a way that lets attackers cross-reference and target them. The breach is fake. The exposure is partly real.

Second, fake breach claims are weaponized for follow-on attacks. Even if OnlyFans was not actually breached, attackers can run phishing campaigns telling users "we detected your account in the OnlyFans leak, click here to verify your password." That phishing email feels plausible precisely because the (fake) breach story was so widely reported. The hoax does thier marketing work for the real attack that comes afterward.

Third, this is the new normal. As real major breaches get harder (improvements in password hashing, multi-factor authentication, supply-chain security), attackers increasingly turn to enrichment of existing data. The 340 million OnlyFans listing is not an outlier. It is what most "new" breach announcements actually are.

The OnlyFans angle: why this platform is particularly vulnerable

Beyond the general data enrichment problem, OnlyFans has a specific vulnerability profile that makes it an attractive target for fake breach campaigns even when no real breach exists.

The platform's value proposition is anonymity. According to OnlyFans' 2024 annual report, the platform had 377.5 million fan accounts and 4.634 million creator accounts in the fiscal year ending November 2024, with gross revenue of $7.22 billion. Many of those users specifically depend on the platform keeping their identity private. A creator may have a public OnlyFans persona while keeping their legal name, day job, and personal social accounts completely seperate. A subscriber may have a private kink they would never disclose to their employer, family, or partner.

When a "breach" links those identities together (even speculatively, even if the data is partly fabricated), the damage is real. Once a connection exists in a database, it can be searched, scraped, and weaponized. Employers checking job candidates, divorcing spouses' attorneys, harassment groups, doxxing communities, all of them now have a starting point even if the original linking was bogus. The cost of correcting a false claim is enormous. The cost of generating it is roughly $76,000 in this case.

This is why the OnlyFans hoax went viral while a similar fake "Spotify breach" might not have. The anonymity stakes are higher. The platform is also the kind of target that media organizations cover, which guarantees that any breach claim gets amplified beyond the cybersecurity community.

Stale breaches keep getting recycled

The OnlyFans incident is a useful illustration of a wider pattern. Old breach datasets do not die. They get recombined and remarketed indefinitely.

Some of the data still actively in circulation:

These compilations form the substrate for almost every enrichment attack. They are public knowledge in cybersecurity research and freely available on the same forums where the OnlyFans listing appeared. Every "new" breach you read about probably draws on at least one of them.

Your email address appears in at least one of these collections with very high probability. According to Have I Been Pwned, the average internet user with a primary email account dating back more than five years appears in 8-12 separate breach databases. That is not a vulnerability you can patch on your end, because the data is already out there.

What you can actually do

You cannot unleak data that is already public. You can reduce its usefulness to attackers.

Check your exposure. Visit haveibeenpwned.com and search your email addresses. The site will tell you which breaches your email has appeared in. This does not undo the exposure, but knowing where you have been compromised helps you understand the realistic threat model.

Use unique passwords per service. The reason credential stuffing attacks work is that people reuse passwords. If your old Spotify password is the same as your bank password, the bank is one breach away from being compromised. A password manager (1Password, Bitwarden, KeePassXC, even browser-built-in managers) eliminates this risk entirely. Use one. Yes, set it up tomorrow.

Email aliases for non-critical services. Apple's "Hide My Email," SimpleLogin, Anonaddy, and Firefox Relay let you create a unique email address for each service you sign up for. If one service is breached, the leaked email points to only that service, not to your entire online identity. The downside is more complexity. The upside is that enrichment attacks become much harder because there is no universal email to match across databases.

Different usernames across platforms. Reusing the same handle on every service creates a free enrichment graph for attackers. If your username on OnlyFans matches your handle on Twitter, the linking has already been succesfully done for the next data enrichment seller. Vary your handles, especially for accounts you want to keep separate.

Two-factor authentication on email. The single most important account to protect is your primary email, because it is the recovery method for every other account. Use hardware-based 2FA (a YubiKey, Google's Titan key, or a passkey) on your main email account if you do anything else from this list.

The IP intelligence angle: enrichment beyond stolen data

For service operators reading this, there is a parallel problem worth understanding. Data enrichment is not limited to leaked credentials. It also happens through behavioral and network signals.

Once an attacker has a profile linked to an email address, they can extend that profile by watching the IP addresses associated with logins to other services, by matching device fingerprints across sessions, and by enriching with public WHOIS, ASN, and geolocation data. Tools that legitimately exist for security research (an email header analyzer for tracing message origin, a reverse IP lookup for finding sites on the same server, an email security checker for validating SPF/DKIM/DMARC records) are the same tools attackers use to build profiles. The difference is intent, not method.

For operators, the implications are concrete. Treating an email address as a stable identifier of "the same user" across sessions is no longer safe, because email addresses are widely available to attackers from enrichment databases. Modern account security has to layer behavioral signals (typing patterns, mouse movement, request timing), device fingerprints (browser, OS, hardware), and network signals (ASN, geolocation, connection type) into a continuous trust score. None of these are foolproof individually. Combined, they are much harder to forge than a single email-and-password pair.

What companies should learn from this

Even when a fake breach is debunked, the company at the center of the claim pays a real cost. OnlyFans spent days defending itself against an attack that never happened, and many users still believe the breach was real. The communication challenge alone is enormous.

For any platform large enough to be a plausible enrichment target (which by 2026 means almost any consumer-facing service with more than a million users), the right defensive posture has shifted. The old model was "prevent breaches." The new model has to be "prevent breaches and respond to fake breach claims as if they were real, because the damage curve is similar."

Practical steps for platforms:

• Monitor leak forums for mentions of your service. Several commercial services (Recorded Future, Have I Been Pwned for Enterprise, Intelligence X) do this as a paid offering. Free alternatives exist for smaller teams.
• Have a pre-written incident response plan for fake breach claims. The press cycle moves faster than verification, so the official response has to be ready before the news breaks.
• Build internal capability to validate whether an alleged leak actually contains your real user data. Field name analysis, sample record checks, and metadata review can usually distinguish real from fake within hours.
• Treat suspected enrichment campaigns as phishing precursors, not isolated events. A fake breach claim is often the first stage of a targeted phishing campaign that follows within days.

Wrap up

The 340 million OnlyFans listing is almost certainly not a real breach. The data was not exfiltrated from OnlyFans systems. The seller has admitted as much. Troy Hunt and other researchers have laid out technical reasons to disbelieve the original claim.

What is real is the methodology. Data enrichment attacks, where attackers combine old breaches, public profile data, and partial fabrications to manufacture a "new" breach, are now a standard tool of the cybercrime economy. They are cheap to produce, easy to market, and effective at causing reputational damage even when the underlying data is junk. Some of the records in any given enrichment dump are accurate, which makes the whole thing impossible to dismiss out of hand.

The lesson for individuals is straightforward. Assume your email and password from any service you used before 2020 has already leaked. Treat your main email account as the linchpin and protect it accordingly. Use unique credentials per service. Where anonymity actually matters, use email aliases and varied usernames so that an enrichment attack cannot link your accounts together.

The lesson for platforms is harder. The defensive perimeter is no longer just your own systems. It is also every previous breach of every other service your users have ever signed up for. You inherit that exposure whether you like it or not, and the next "your service was breached" story might be entirely manufactured. Have a plan for that day.

Sources include reporting by Hackread (initial seller contact via Telegram), Cybernews (sample record analysis), Security Affairs, IBTimes UK, and public commentary by Troy Hunt on X. OnlyFans denied any breach in a statement published on May 25, 2026. Technical details of the listing are accurate as of the article date but the broader attribution remains contested.