Facebook Scraped 533 Million Records Through a Broken API Feature

Attackers pulled names, phone numbers, emails, and locations from 533 million Facebook accounts by querying a Contact Importer feature that accepted requests without proper authorization checks. The data later appeared for sale on forums after the vulnerability had already been patched in 2019. No credentials were stolen and no MFA was involved because the attack never touched authentication at all.

Facebook's Contact Importer let users upload phone numbers to find matching accounts. The same endpoint accepted automated queries that returned personal details for any phone number without verifying the requester had a legitimate relationship to those numbers. Attackers wrote simple scripts to cycle through ranges of phone numbers and collected the matching records at scale. The feature performed no rate limiting or origin validation that would have stopped this pattern.

The data set included 533 million unique records. Each record contained at least a phone number plus the associated name, email address where available, and location data. Because the queries succeeded without any session token or user consent, the entire harvest required zero interaction with Facebook's login systems.

Why Authorization Controls Failed Instead of Authentication

This incident falls under authorization abuse. The server accepted requests that should have been rejected based on who was asking, not whether the asker had logged in. Legacy MFA addresses only the credential phase before a session is created. Once the API endpoint itself grants access without a session, no second factor can intervene.

Facebook disclosed the issue in April 2021 after researchers found the scraped data circulating on forums. The company stated the vulnerability had been fixed in 2019, yet the earlier window was sufficient to collect the 533 million records. No evidence emerged of stolen passwords, session cookies, or SAML assertions because none were needed.

The Real-World Cost of One Misconfigured Endpoint

The exposed records later fueled targeted phishing campaigns and SIM-swapping attempts against the affected users. Facebook faced regulatory scrutiny in multiple countries over the scale of the leak. The company did not report a ransom payment because the data was simply taken, not encrypted for extortion.

The same pattern appears whenever an API or feature trusts the caller without enforcing least-privilege checks. Adding OTPs or push notifications would have changed nothing here; the requests never reached an authentication gate.

The fix isn't complicated, but it requires a new way of authentication and authorization. The full technical breakdown of what actually works is at mfa2point0.com.

FAQ

Did MFA play any role in stopping or failing during the Facebook scraping incident?

No. The Facebook data breach involved direct API queries against the Contact Importer feature. No login, password, or second factor was ever presented, so MFA had no opportunity to act.

How many records were actually taken in the Facebook breach?

Researchers confirmed 533 million unique user records containing phone numbers, names, emails, and locations were scraped and later posted publicly.

Was the vulnerability still active when the data appeared on forums?

Facebook stated the Contact Importer flaw was patched in 2019. The data set that surfaced in 2021 had been collected during the earlier exposure window.

Could stronger login requirements have prevented this scrape?

Stronger login requirements would not have helped. The attackers never logged in; they simply queried an endpoint that did not enforce proper authorization for the requested data.