MyRecon OSINT

← Case Files · The Breach Files

2022 · Social network

Twitter, 2022: an API that confirmed which account owned which email

Case file · 3 min read · Published 14 September 2026

People affected
5.4 million accounts confirmed; a larger compilation circulated later
When it happened
June 2021 – January 2022
Made public
August 2022
How they got in
An API flaw allowing an email address or phone number to be resolved to an account
Attributed to
Reported responsibly in January 2022; the data was later sold and then published
What it cost
Regulatory inquiry in Ireland; irreversible deanonymisation for affected users

What was exposed: Email addresses · Phone numbers · The linked account handle and public profile data

The Twitter incident of 2022 exposed no passwords, no messages and no payment details. It exposed a mapping: this email address belongs to that account. For a platform where a large number of people deliberately keep their name and their handle apart, that single fact was the most damaging thing that could have leaked.

What happened

A change introduced to a Twitter API in June 2021 meant that an email address or phone number submitted to a particular endpoint would return the account associated with it. Contact-matching features work this way by design — it is how "find your friends" works — but exposing it in this form, at scale and without adequate limits, turns it into a lookup service.

A researcher reported the flaw through Twitter's bug bounty programme in January 2022 and was paid; the flaw was fixed. Before that, however, someone had used it to build a dataset.

In July 2022 a file covering 5.4 million accounts was offered for sale. Twitter confirmed the vulnerability and the resulting exposure in August. The data was later published freely, and in early 2023 a much larger compilation circulated, which analyses suggested was substantially the same extraction combined with other scraped material rather than a fresh breach.

Enumeration is a category, not an accident. Any function that answers "does an account exist for this identifier?" can be turned into a directory by someone willing to ask enough times. The same failure produced the 533 million Facebook records. The fix is never to remove the feature; it is to make bulk use expensive — rate limits per identity rather than per address, anomaly detection on query patterns, and returning answers that do not confirm existence to unauthenticated callers.

Why deanonymisation is a different kind of harm

Most breach advice is about remediation: change this, freeze that, watch for the other. None of it applies here, because there is nothing to change.

Consider who uses a pseudonymous account and why:

  1. People writing about their own health, sexuality or faith in contexts where being identified carries real social or legal consequences.
  2. Sources and whistleblowers, whose safety depends on their contact with journalists being unattributable.
  3. Activists and dissidents in countries where an identified critic is arrested rather than argued with.
  4. People who have left abusive relationships, for whom the link between an identity and an account is a physical safety matter.
  5. Ordinary people who simply preferred that their employer not read their opinions.

For every group on that list, the mapping is the harm, it is permanent, and it was published.

What it changed

Enumeration protections became standard. Platforms reviewed every endpoint that confirms an identifier resolves to an account — registration forms, password reset flows, contact matching — and moved to responses that do not distinguish between existing and non-existing accounts.

Pseudonymity got treated as a security property. It had often been framed as a nuisance in policy debates about real-name requirements. This case forced a clearer articulation of what pseudonymity protects and who relies on it, and it fed directly into European regulatory scrutiny of platform design.

The lifecycle of a reported bug got attention. The flaw was responsibly reported and fixed; the damage had already been done in the seven months it was live. Fixing a vulnerability does not remediate the exploitation that preceded it, and incident response has to start with "what was taken before we closed it?", not "is it closed now?".

If you use a pseudonymous account anywhere

  1. Register it with an address and number that are not linked to your name. A dedicated email address used for nothing else is the single most effective separation available.
  2. Do not attach a phone number you use elsewhere. Where two-factor authentication is required, use an authenticator app rather than SMS — the practical differences.
  3. Assume the link can be made and plan for it. If being identified would be dangerous, treat the account as potentially identifiable and post accordingly.
  4. Audit what your accounts already reveal about each other — reused handles, profile photos, writing style and posting times all link identities without any API assistance — how that correlation actually works.

Checked against every breach on record, against public breach data only. Your address is not sent to us as a form and is not stored — it is handed straight to the lookup tool in your own browser. See the privacy policy.

Questions people ask

What was the actual bug?

A change introduced in 2021 meant that submitting an email address or phone number to a particular endpoint would return the associated account, if one existed. That is a feature in a contact-matching context and a deanonymisation tool in a platform where many users deliberately keep their identity separate from their handle.

Why is this worse than a password leak?

Because you can change a password. You cannot unlink a real identity from a pseudonymous account once someone has published the mapping. For activists, journalists' sources, people writing under a pseudonym about their health or sexuality, and anyone in a country where their speech is criminalised, that link is the thing the account existed to protect.

Was it reported responsibly first?

Yes. A researcher reported the flaw through Twitter's bug bounty programme in January 2022 and was paid for it, and the flaw was fixed. The data had already been extracted before the fix, and it was offered for sale that July and published later.

What about the "200 million" dataset?

A larger compilation circulated in early 2023. Analyses indicated it was substantially derived from the same underlying extraction, deduplicated and combined with other scraped data, rather than being a new and separate breach. As with all aggregate claims, the unique-record count is the number that matters.

Sources

Read next

Case files are written from the public record: regulatory findings, court filings, company disclosures and contemporaneous reporting, cited above. Figures are the ones the organisation or its regulator finally settled on, which is often not the number first reported — where that differs, the page says so. Disputed accounts are marked as disputed rather than resolved in either direction.

← All case files Breach archive →