how it happened
- whoactor500M breached emails
- the gappublic APIno login, no volume limit
- the result~15M recordsnames and usernames leaked
what everyone assumed
Public means public, and a profile that anyone can already see does not feel like data worth defending. The reasonable belief is that an exposure only counts when something secret leaks, so an open endpoint returning a name and a username sits comfortably in the harmless column. The risk does not arrive in any single answer. It arrives in the volume of answers, and volume is hard to see one request at a time.
what happened
The endpoint allowed anyone, without authenticating, to map an email address to a Trello account. On its own that was a feature. At scale it was a compiler: an actor took a list of roughly 500 million email addresses drawn from earlier breach collections, and queried the endpoint against each one to learn which addresses belonged to Trello accounts and what profile sat behind them. There was no break-in. No password fell. The system was answering ordinary, permitted questions, a very large number of them, and nothing about that volume tripped a line, because the line had not been drawn at volume.
step by step
- an endpoint maps an email to an account without loginOn its own, a feature.
- 500 million breached emails are fed to itNothing limits the volume.the assumption breaks here
- about 15 million records assembledEmails linked to names and usernames.
- July 2024dumped publicly; the API is changedNo systems were breached.
how it surfaced
The compiled dataset, roughly 15 million records linking email addresses to names and usernames, surfaced for sale and was later dumped publicly in July 2024. Atlassian, which owns Trello, confirmed no unauthorized access to its systems had occurred and adjusted the API so that unauthenticated callers could no longer request another user’s information by email. The records were not stolen so much as assembled, each one public, the set as a whole something that had never existed in one place until an endpoint built it on request.
Public data is safe in ones and dangerous in bulk.
The moment an interface answers the same harmless question millions of times without friction, it stops returning facts and starts building a list, and the list is the asset.
picture it at a company like yours
The company here is made up. The other two paths are not: they happened, and each links to the story.
- in this storythe day it mattersSomeone checks millions of leaked email addresses against your app.what it costs youA list of your users, with names, is assembled and sold. Nothing was hacked.
- or it goes like thisit happenedDell, 2024howA partner lookup answers one order number after another, all day, for weeks.what leavesnames, addresses and orderswho ends up with ita seller on a criminal forum
- or it goes like thisit happenedTwilio Authy, 2024howA phone-number check is run against millions of numbers.what leaveswhich numbers belong to your userswho ends up with itpeople planning SIM swaps
sources
your turn
what you can do about it
this week
List the unauthenticated endpoints that take a known input and return a record, and check whether any of them will keep answering at scale, then look at where rate limiting and monitoring would notice a million questions arriving as one.
Somewhere you expose an endpoint that returns harmless public information to anyone who asks, with no login and no limit, because each answer is fine. That assumption is the gap.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →