how it happened
- whoattackerfound a token in GitLab
- the gapexposed tokenled past the login
- the result31M accountsemails and hashed passwords
what everyone assumed
A team salts and hashes its passwords with bcrypt, which is the right thing to do, and from there the reasoning runs that a stolen authentication database is a contained problem: the hashes are slow to crack, so the data is effectively inert. That belief is mostly sound for the passwords themselves. It quietly assumes the database is hard to reach in the first place, and that the thing protecting the user records is the hashing rather than the door in front of them.
what happened
The exposed token was the door. While the hashing held, the path to the data did not depend on cracking anything, because an unrotated credential left in source control led straight to the systems behind the login. The most recent record in the eventual dump was timestamped September 28, 2024, the likely moment the database was taken. For roughly two years before that, the only thing standing between the user records and an outsider was a token nobody had rotated.
step by step
- an access token is left in source controlNot rotated for roughly two years.the assumption breaks here
- 28 September 2024the user database is takenThe token leads straight past the login.
- October 202431 million records surfaceEmails, screen names and bcrypt hashes in a 6.4 GB file.
- a second intrusion via unrotated API tokensThis time into the support platform.
how it surfaced
In October 2024, a database holding around 31 million records surfaced: email addresses, screen names, password-change timestamps, and bcrypt-hashed passwords, in a 6.4 GB file. The hashing did its job; the hashes were not the exposure that mattered. The 31 million email addresses and the access path itself were. A separate intrusion around the same time reached the Archive’s support platform through unrotated API tokens.
Hashing protects the passwords. It does nothing for the door to the database.
What exposed 31 million records was a working credential left in source control for two years, and no hash function defends against an unlocked door.
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 finds the key and walks straight past your login page.what it costs youYour user database is copied, and the key had been valid for years.
- or it goes like thisit happenedCash App / Block, 2022howThe person logs back in from home, weeks after leaving.what leavescustomer lists and reportswho ends up with itthe former employee and whoever they work for next
- or it goes like thisit happenedColonial Pipeline, 2021howThe forgotten account's password turns up in a breach dump.what leavesa working way into the networkwho ends up with ita ransomware crew
sources
your turn
what you can do about it
this week
Scan your source control history for live tokens and keys, not just the current branch, and rotate anything that still authenticates.
Your repositories contain secrets you have forgotten: a token committed during a deploy two years ago, a key in an old config file, a credential someone pasted into a script "just to test it." The assumption to retire is that hashing your passwords makes the auth database safe, because the database is only as protected as the credentials that reach it. The Internet Archive's exposure lived in that history for two years before anyone read it out.
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 →