Exposed Credential Database

Researchers found a publicly exposed Elasticsearch database containing 24 billion stolen credential records and more than 8.3TB of data. The contents include usernames, email addresses, plaintext passwords, login URLs and source details tied to each record.

This is not a breach of an organisation. It is a criminal aggregation of material taken from many breaches and infostealer infections, which was itself left reachable without authentication. The owner is unknown and the exposure was found through survey work rather than reported by anyone responsible for it.

Usernames, email addresses, plaintext passwords, login URLs and source metadata.

The login URL is the field that turns a password list into an operational tool. A credential without context requires guessing where it works. A credential paired with the exact login page it came from is immediately actionable, which is why these collections are assembled this way and why 8.3TB of them has practical value to an attacker.

Effectively anyone with accounts online, which is not a useful statement, so the narrower one: everybody whose credentials appeared in any source breach or infostealer log feeding this collection.

Nobody in this dataset can be notified. There is no controller, no notification duty and no list of affected parties to work from. The only practical defence is the one people were already advised to take, which is not reusing passwords, and the existence of 24 billion records suggests how widely that advice goes unfollowed.

Nothing to assess, because the holder is a criminal operation. Including it in this series is deliberate for the opposite reason.

The organisations whose credentials are in here did everything from the normal range: some were breached, some had users infected with infostealers, some had both. The aggregation happened downstream of every control any of them operated.

For the collection's owner, apparently the same thing that has caught organisations throughout this series: that their own data store was reachable without authentication.

There is something clarifying about an attacker making the exact mistake the Supabase entry in this series documents. Misconfiguration does not discriminate by intent. A database that answers unauthenticated requests will answer anyone's, and the operator's sophistication at taking data has no bearing on their competence at storing it.

The more useful question for a defender is how many of your users' credentials are in there, and that is answerable by checking your own authentication logs for credential stuffing patterns rather than by waiting to be told.

There is no attacker to attribute in the usual sense. The collection was assembled from many sources over time, and the party that assembled it has not been identified.

Researchers finding it first is luck. Internet-wide scanning is continuous, and an open Elasticsearch cluster of this size would not have gone unnoticed by anyone else looking.

For the individuals, unique passwords and multi-factor authentication, which blunts the entire category.

For organisations, treating credential stuffing as the expected baseline rather than an event. A collection of this size means that for any service of reasonable scale, some fraction of your users' passwords are already in criminal hands, and the defences that matter are the ones that assume that is true.