Post-breach data control

149 million passwords exposed: why credential leaks are becoming the new normal

An exposed database of 149 million credentials points to infostealer malware on endpoints, and to why controls must hold after credentials leak.

In January 2026 a security researcher reported finding a publicly accessible database containing around 149 million usernames and passwords, covering email providers, social networks, streaming services, financial platforms and some accounts linked to public institutions. As reported, the database had no password or encryption; anyone with the address could read it.

Not a platform breach, an endpoint problem

The services involved were not "hacked" in the usual sense. The credentials appear to have been collected over time by infostealer malware on individual devices, and then aggregated elsewhere.

Infostealers typically arrive through malicious downloads, fake updates, cracked software or compromised browser extensions. Once installed, they collect:

  • saved browser passwords
  • session cookies and authentication tokens
  • autofill data
  • crypto-wallet keys

The data is then uploaded to servers that are often poorly secured, as in this case. The lesson is uncomfortable: an organisation can secure its own servers well and still lose its users' credentials, because the weak point is the device.

Why leaks like this last

Leaked credentials create long-tail risk. Even old passwords can be used for credential stuffing where passwords are reused, for account takeover without exploiting any vulnerability, and for convincing phishing that quotes real details. Many organisations only learn that credentials are circulating when fraud or extortion has already started.

Hygiene is necessary, not sufficient

The standard advice remains right: do not reuse passwords, use multi-factor authentication and use a password manager. Phishing-resistant authentication and short-lived sessions help further. But these controls are about preventing access. Once valid credentials or session tokens are in circulation, an attacker can look like a legitimate user.

That is why the questions are shifting from "are we secure or compromised?" to "what still holds after something leaks?":

  • Can access be re-evaluated when the device or context looks wrong, even if the credentials are valid?
  • Can the use of sensitive data be tied to approved devices and purposes, not just to a login?
  • Can we see what was requested with leaked credentials, and what was allowed?

Where post-breach data control fits

PastWipe™ addresses part of that problem for selected high-value data. It re-checks identity together with device, environment, purpose and the current security state at the point of use, and records each decision. A valid login from an unapproved device can be denied, or given a degraded view of protected data.

It does not stop credentials leaking and it does not replace identity controls. It reduces the usable value of protected data when access is attempted outside approved conditions.

How PastWipe works · Contact us

All insights and news · Get the quarterly Post-Breach Briefing