Twitter 5.4M Accounts Scraped via API Flaw With No Login Required

Twitter's disclosure stated that the attackers found an API endpoint tied to an internal tool used for account management. The endpoint accepted queries for account identifiers and returned associated email addresses and phone numbers without verifying that the caller had permission to view that data. No password, session cookie, or OAuth token was presented or required. The company reported that the flaw affected accounts created before mid-2021, when stricter controls were added.

The attackers automated calls to the endpoint and collected records at scale. According to Twitter's July 2022 statement, roughly 5.4 million accounts had at least one piece of contact data returned. No evidence emerged of stolen credentials or compromised employee accounts being used to reach the endpoint. The breach was therefore an authorization failure at the application layer, not an authentication failure.

According to Verizon's 2023 DBIR covering 2022 incidents, stolen credentials remain the leading initial access vector in breaches, yet API and web application flaws still account for a measurable share when authorization logic is incomplete. This incident fits that pattern exactly.

Why No Authentication Barrier Existed

Because the endpoint returned data without checking identity or permissions, there was never a point where a password, OTP, or hardware key could have intervened. The request succeeded on its first try. Attackers did not need to phish anyone, reuse a session token, or trick a helpdesk into resetting anything. The data simply should not have been reachable through that path.

In incidents where credentials are stolen first, time-based OTP or push factors can sometimes block the initial login. Here the entry method bypassed the login process entirely. Any discussion of authentication therefore starts from the wrong assumption that an authentication event took place.

Twitter later restricted the endpoint and added authorization checks. The company did not publish details on how the internal tool had been built or why the missing checks were not caught earlier. Public reporting at the time noted that similar API exposure issues had appeared in other platforms when internal tooling was insufficiently isolated from external callers.

Blast Radius and What Was Taken

The scraped fields included email addresses and, for some accounts, phone numbers linked to the profile. Twitter stated that full names, usernames, and follower counts were already public and therefore not part of the new exposure. The company notified affected users and offered a short window to reset passwords as a precaution, even though no passwords were involved in the scrape.

The absence of any authentication step meant the attackers could repeat queries from any network location without leaving the usual login artifacts. No session tokens were captured or replayed because none were issued. The operation stayed entirely in the authorization layer.

The same authorization gap has appeared in other platforms when internal tools were exposed without proper permission boundaries.

The full technical breakdown of what actually works is at mfa2point0.com.

FAQ

How did the attackers reach 5.4 million Twitter accounts without logging in?

The attackers reached the accounts by calling a Twitter API endpoint that returned email addresses and phone numbers without requiring any authentication or authorization check. Twitter's disclosure confirmed the endpoint was part of an internal tool and lacked permission validation, allowing automated scraping of 5.4 million records.

Would any form of MFA have stopped the Twitter API scraping incident?

No form of MFA would have stopped the Twitter API scraping incident because the attackers never attempted to authenticate. The endpoint accepted requests and returned data without checking identity or permissions, placing the failure outside the scope of any login factor.

What exactly was exposed in the 2022 Twitter breach?

The 2022 Twitter breach exposed email addresses for all 5.4 million affected accounts and phone numbers for a subset of those accounts. Twitter stated that usernames and public profile data were already visible and not newly compromised by the scrape.

Did Twitter's later changes close the specific API gap?

Twitter restricted the affected endpoint and added authorization checks after discovering the flaw. The company did not release further details on the original code path or detection timeline beyond the July 2022 public statement.

How does this case differ from credential-based Twitter incidents?

This case differs because no credentials, OTP codes, or session tokens were stolen or reused. Attackers simply reached data that the API should never have returned to an unauthenticated caller, unlike breaches that begin with a successful login.