By ByteBot
On June 12, researchers found an open Elasticsearch cluster holding 24 billion credential records — 8.3 terabytes, every password stored in plaintext. Have I Been Pwned ingested 56.3 million email addresses and 124 million unique passwords from the dataset three days later. If your application has a login page, your users are in this dump. The question is whether your app is ready to handle what comes next.
This Is Not a Typical Data Breach
Most credential dumps are old hashes cracked over months. This one is different. The 24 billion records are infostealer logs — output from malware that runs silently on a victim’s device, scrapes every saved browser password, active session cookie, and autofill entry, then self-destructs before antivirus catches it. The data came from 36-plus sources including Telegram cybercrime channels and breach compilation packs.
Researchers found that 98.6% of processed infostealer packages contained active, working credentials, with URLs identifying exactly which service each email-password pair unlocks. Attackers are not guessing. They have a map. The difference from a classic breach is that these are your users’ current, active passwords — not a 2021 hash dump they may have rotated out of circulation.
Your Login Endpoint Is Already Being Tested
Credential stuffing is not sophisticated. Attackers load the list into OpenBullet 2 — an open-source, no-code automation tool — configure it for your login endpoint, attach a list of residential proxies to distribute the traffic below per-IP rate limits, and let it run. Success rates of 0.1% to 2% sound small until you remember there are 24 billion records to try. Bots now generate more traffic than humans on authentication surfaces in fintech, SaaS, and gaming.
The goal is account takeover: extract stored payment methods, drain credits, resell accounts, or pivot to internal tooling if the compromised account has elevated access. Every unprotected login page is a target right now.
Four Things to Fix Before This Week Is Over
1. Audit Your Password Storage
If you are storing passwords with MD5, SHA-1, or unsalted SHA-256, you have an emergency today, not a backlog item. Migrate to Argon2id with parameters m=19456, t=2, p=1 — the OWASP 2026 baseline. Argon2id is memory-hard, resistant to GPU attacks, and recommended by every major security body. Bcrypt at cost 12 is acceptable if you are already using it; cost 13 if your server load allows. Do not stay on MD5 or SHA-1 for one more sprint.
2. Check Passwords Against HIBP on Login and Registration
The Pwned Passwords API is free and privacy-preserving via k-anonymity: SHA-1 hash the candidate password, send only the first five characters to api.pwnedpasswords.com/range/{prefix}, and check the response locally. Your server never sends the actual password or even its full hash over the wire. 124 million new entries were added on June 15. Block or warn users when a submitted password appears in the database.
import hashlib, requests
def is_password_pwned(password: str) -> bool:
sha1 = hashlib.sha1(password.encode()).hexdigest().upper()
prefix, suffix = sha1[:5], sha1[5:]
resp = requests.get(f"https://api.pwnedpasswords.com/range/{prefix}")
return any(line.split(":")[0] == suffix
for line in resp.text.splitlines())3. Enforce MFA — and Understand Its Limits
MFA stops credential stuffing cold: the attacker cannot authenticate with a valid password alone. Require it, especially for accounts with payment access or administrative permissions. But be precise about what MFA actually protects. Infostealers steal active session cookies as well as passwords. If a user’s device was infected, their session token may already be in the hands of an attacker who can replay it without triggering a login prompt at all. MFA guards the authentication event. It does not guard an already-authenticated session running on a compromised machine.
Implement session expiry, re-authentication gates for sensitive operations, and consider device binding for high-value accounts. MFA is mandatory; it is also not the whole picture.
4. Rate-Limit Per Account, Not Just Per IP
Modern attacks distribute login attempts across thousands of residential proxies. Per-IP rate limiting alone fails because each proxy IP stays under any threshold you set. Limit failed attempts per account — five per 15 minutes is the documented industry reference — independent of which IP sent the request. Combine this with soft fingerprinting: IP address, User-Agent, Accept-Language header, and TLS fingerprint (JA4 is replacing JA3 in 2026 tooling) together are harder to spoof than IP alone. Add IP reputation checks upstream: flag datacenter ranges and known proxy services aggressively before rate limits engage.
The Real Fix Is Passkeys
Credential stuffing is an attack against a password-based authentication system. Passkeys (FIDO2) eliminate the attack surface entirely — there is no shared secret to steal, reuse, or brute-force. Apple, Google, and Microsoft now support passkeys natively. If you are building a new authentication flow, passkeys should be the default path. For existing applications, adding passkeys as an option and nudging users toward adoption removes the most dangerous category of your exposure over time.
Meanwhile, the threat is escalating. The dataset includes a subset enriched with live CVE data, cross-referencing stolen credentials with systems running known vulnerabilities. AI is automating that correlation at scale. The gap between a leaked password and a targeted attack is narrowing fast.
