In April 2021, a dataset containing personal details of 533 million Facebook users — phone numbers, names, locations, email addresses — appeared for free on a hacking forum. The data was old, scraped via a now-patched contact-import flaw years earlier. The incident nevertheless burned: “old” breach data never dies, because people keep phone numbers for a decade and attackers keep datasets for life. It became the definitive case study in scraping-as-breach and the long tail of data exposure.
The 533M-record dataset (covering users across 100+ countries, ~32M US records, ~11M UK) derived from a contact-import vulnerability Facebook abused — an API weakness let attackers match phone numbers to profiles at scale — abused from 2018–2019 and fixed by September 2019. A subset surfaced for sale in January 2021 (bot ads asking ~$750/category), then the full set was dumped free in April 2021. Facebook declined notification, arguing users could not be individually identified from public filings. Core lessons: scraped data breaches count as breaches in impact (spam/SIM-swap/phishing fuel), data age reduces sensitivity slowly, and contact-import APIs are a disclosure-class design flaw that every platform must control via rate-limits and enumeration guards.
What happened
The mechanics were simple and, at the time, common: Facebook’s contact-uploader let a user upload a phone number list to find friends. Abused programmatically, the same function let an attacker enumerate numbers and harvest the linked profile data — name, relationship status, occupation, location, and more per matching record. Facebook closed the vulnerability in 2019, but the scraped dataset lived on in trader circles. In January 2021, a Telegram bot advertised lookup access for a price; by April, the full dump was free on a public forum, with per-country files and record counts.
The April dump’s promotional message even credited the January seller as the source — a small detail that illustrates the breach-data economy’s marketing norms: provenance bragging, category pricing, then free release when freshness decays. For 533 million people, the practical outcome was a permanent increase in targeting quality for spam, vishing, SIM-swapping (phone number + name + city is a strong swap kit), and password-reset attacks against other services reusing phone-based recovery.
Facebook’s response drew as much attention as the leak: the company said it was old data from a fixed issue, that it would not individually notify affected users because identifying them from the dump was impractical, and pointed to its 2018–2019 fix timeline. Regulators disagreed with the posture — Ireland’s DPC investigated (with the ICO cooperating), forwarding findings toward the EU/EEA authorities; the episode sharpened the global debate over whether scraped-data exposure triggers notification duties even when no “unauthorized access to systems” occurred in the classic sense.
How it worked
The vulnerability class is contact-import enumeration — a design weakness, not a memory bug:
attacker workflow (2018–2019 window):
1) generate candidate phone list (country ranges, prefix rules)
2) bulk-upload to contact-import API ("find friends")
3) API returns matched profiles: name, photo link, city,
relationship/job fields, account id, some emails
4) rotate batches until target countries exhausted
5) store, then monetise: lookup bot (Jan 2021),
paid bundles, free dump (Apr 2021) when value decays
why it worked:
- API designed for friend-discovery, not adversarial volume
- no enumeration rate-limits per account/IP at the time
- response richness (identity fields) high for a "matcher"The defensive counter-patterns are now standard in API security reviews: treat every lookup/matching endpoint as an enumeration oracle until proven otherwise; apply per-identity and per-IP rate curves; return minimal fields on match (confirmation factors only); and monitor for cycle-pattern uploads (sequential ranges, uniform batch sizes). Our phishing-evolution analysis covers how high-quality dumps like this raised phishing’s yield for years — the dataset’s real product was targeting confidence.
Impact and numbers
| Metric | Value | Source |
|---|---|---|
| Total records | 533M users, 106 countries | dump analysis (Apr 2021) |
| US / UK records | ~32M / ~11M | press analyses |
| Original vector | Contact-import vulnerability abused 2018–2019 | Facebook statements |
| Fix date | September 2019 | |
| January 2021 pricing | Telegram bot, per-country/category fees | listing screenshots |
| Regulatory response | DPC (Ireland) investigation; ICO cooperation | regulator statements |
Timeline
| Date | Event |
|---|---|
| 2018–2019 | Contact-import abuse window; scraping at scale |
| 2019-09 | Facebook patches the vulnerability |
| 2021-01 | Telegram bot sells lookups/bundles |
| 2021-04-03 | Full dataset dumped free on forum |
| 2021-04 | Press storm; Facebook “old data” stance; DPC probe |
Why it still matters in 2026
The dataset is still circulating and still effective, because its key fields decay slowly: people change phone numbers far less often than passwords. Every vishing wave, SIM-swap kit, and targeted smishing campaign since 2021 has drawn on this and sibling dumps — making it a permanent line item in phishing-attack economics. For platforms, it remains the canonical scraping case: nowadays “data exposure via API abuse” is treated as a breach-class event (GDPR’s subsequent scraped-data case law moved that way), and contact-import/matching endpoints everywhere carry enumeration controls in review checklists. For individuals and defenders, it cemented the phone-number-as-identifier problem — the argument at the heart of modern identity attack analysis: identifiers that cannot be rotated are permanent targeting surface.
Detection and hardening takeaways
- Treat matching endpoints as oracles. Any API that answers “does this identifier exist, and whose is it?” must carry aggressive per-account and per-IP rate limits, anomaly detection on sequential-range uploads, and minimal response payloads.
- Classify scraped-data events as breaches in impact. Notification, regulator engagement, and user guidance may be warranted even without classic system intrusion — the phishing/SIM-swap fallout is identical to a “real” breach.
- Assume number-linked data is public. Design account recovery so phone-based reset alone cannot compromise an account; require a second factor not derivable from any dump.
- Reduce identifier richness. Don’t return emails, exact locations, or relationship data from lookup flows; every extra field converts a matcher into an identity-resolution service for attackers.
- Monitor dump markets for your users. Threat-intel programmes should watch lookup bots and forum dumps for their customer/employee datasets — early sighting lets you pre-empt targeted campaigns with warnings and tightened reset paths.
FAQ
Was this a “hack” of Facebook’s systems?
Not in the intrusion sense. The data was extracted by abusing a legitimate feature (contact importing) beyond its design intent — an API-design weakness rather than a system compromise. Facebook’s position hinged on that distinction; the impact analysis (targeting fuel for phishing and swaps) treated it as breach-equivalent regardless.
The data was from 2019 — was it still dangerous in 2021?
Yes — that was the whole lesson. Phone numbers persist; names and cities persist; the marginal staleness of a two-year-old dataset barely reduced its value for vishing and SIM-swap kits. Free release in 2021 also widened the attacker population from paying customers to everyone, which is why “old leak” never means “safe leak.”
What should an individual have done?
Practical steps: assume the number+name pair is known to attackers; tighten carrier port-out/SIM-security settings; avoid phone-only recovery on important accounts; and treat any caller/SMS referencing your name, city, or workplace as potentially dump-armed. For enterprises, employee-number dumps justify targeted-phishing warning campaigns — the same guidance we give after any modern phishing surge.
