24 Billion Stolen Records: Your Credential Exposure Risk
In June 2026, researchers found a single unsecured database holding more than 24 billion stolen credential records, one of the largest exposures ever cataloged. If your first reaction was "we weren't in that breach, so we're fine," that is exactly the assumption attackers are counting on. The uncomfortable truth is that credential exposure in 2026 is rarely about a breach of your company. It is about the reuse, resale, and replay of credentials your employees and customers already handed to attackers elsewhere, and whether your systems can tell the difference between a legitimate login and a stolen one.
This guide walks through what actually leaked, what an attacker does with exposed credentials, why two of 2026's biggest breaches followed the same playbook, and how a penetration test validates whether your organization is genuinely exposed or just anxious. The goal is not to add another breach headline to your feed. It is to help a CISO or IT director turn breach news into a defensible scoping decision.
What Actually Leaked in the 24 Billion Record Dump
The June 2026 discovery was not a single company breach. It was a compilation: an 8.3-terabyte database aggregated from roughly 36 sources, including Telegram channels, older breach collections, and fresh infostealer malware logs. According to Malwarebytes and Cybernews, which first surfaced the exposure, the records included usernames, email addresses, plaintext passwords, and active session tokens.
That last category is the one most security teams underweight. A breach of hashed passwords ages badly for the attacker as users rotate credentials. A dump of session tokens and cookies is live ammunition, because it can bypass the login step entirely.
The dataset also carried something unusual: more than 9,500 documents referencing CVE identifiers with matching exploit repository links, and thousands of logs tracking recent breach news. In other words, the same collection that carries your employee's reused password also carries a curated map of which vulnerabilities to pair it with. Credential exposure and vulnerability exposure are being packaged together for the buyer.
The database was pulled offline shortly after discovery. That does not help you. By the time a compilation like this is reported publicly, the useful contents have circulated through criminal marketplaces for weeks or months. The question is not whether the data is still online. It is whether the credentials inside it still work against your systems.
Why Credential Exposure Is Now Your Problem, Not the Breached Company's
Here is what most breach coverage misses. When a third party is breached and your employee's work email and reused password land in a dump, the attacker does not need to touch that third party again. They bring those credentials to you.
The mechanics changed with the rise of infostealer malware. According to Flashpoint and Recorded Future data, infostealers infected over 11 million machines in 2025 and produced billions of stolen credentials. An infostealer log from one infected laptop typically contains passwords saved across every browser, autofill data, device fingerprints, and, critically, active session cookies and tokens.
Those tokens are why "we have MFA" is no longer a complete answer. As security researchers documented through 2026, infostealers do not defeat multi-factor authentication. They sidestep it. The malware steals the session token your browser receives after you have already passed MFA, and the attacker injects that token into their own browser to become a logged-in user. The second factor was already satisfied, so it is never challenged again. The 2026 Verizon DBIR reinforced the scale of this: a majority of ransomware victims had their domains show up in infostealer logs before the ransomware ever hit.
The practical consequence for your attack surface is blunt. Every credential your organization has ever created, on any service, in any browser, on any employee device, is a potential entry point that lives outside your perimeter and outside your control. You cannot patch it. You can only test whether it still works and whether your controls catch it when it does.
What an Attacker Does With Exposed Credentials
Exposed credentials are raw material. The value comes from what an attacker does next, and the steps are well-worn enough to be almost procedural. Understanding the sequence tells you exactly what a pentest needs to exercise.
The two dominant techniques look similar but exploit different weaknesses, and defenses that stop one often miss the other.
| Technique | What the attacker has | How it works | What stops it |
|---|---|---|---|
| Credential stuffing | Valid username and password pairs from breaches | Replays known-good pairs across many services, betting on reuse | Breached-password detection, rate limiting, bot detection, MFA |
| Password spraying | A username list plus a few common passwords | Tries one common password against many accounts to dodge lockouts | Login anomaly detection, lockout policy, MFA, disabling stale accounts |
As SpyCloud explains, credential stuffing bets on password reuse across sites, while password spraying bets that at least one account in a large organization uses a weak, common password. A regulated mid-market org with a few thousand accounts almost always loses that second bet somewhere.
From Valid Login to Full Compromise
A successful login is the beginning, not the end. In a SaaS-heavy environment, one valid account often unlocks internal documents, customer records, API keys, and connected third-party integrations. From there the attacker follows a predictable path:
The first move is reconnaissance from inside the account: reading email, shared drives, and internal wikis to learn how the organization is structured and where the valuable systems live. The second move is privilege escalation, using information gathered from the first account to reach an admin, a service account, or a system with broader access. The third move is lateral movement across connected systems, hunting for the data or control that was the actual objective, whether that is a fraud transaction, data exfiltration, or ransomware deployment.
Each of those moves is testable. That is the entire point of connecting breach news to a penetration test rather than to a threat feed. An attacker's path from an exposed credential to a material incident runs through your authentication, your session handling, your authorization boundaries, and your monitoring. A pentest walks that same path deliberately and tells you where it breaks.
See what your external surface exposes, mapped to the controls it touches.
Run a free External Security Check →KDDI and Oracle PeopleSoft: Two 2026 Breaches That Show the Pattern
The 24 billion record dump is abstract. Two July 2026 incidents make the pattern concrete, and both should feel uncomfortably relevant to a regulated mid-market org.
In early July, Japanese telecom giant KDDI disclosed a breach of a shared email platform that exposed up to 14.2 million email logins across six internet providers. Attackers exploited a zero-day in third-party software in mid-May, and the intrusion was not detected until mid-June, a month later. Roughly 12 million email addresses and 7.6 million passwords were exposed. Some passwords were hashed or encrypted, but the company did not specify how many were stored in plaintext.
Two details matter here. First, the initial entry was a third-party software zero-day, not a KDDI-authored bug, the same shared-infrastructure exposure that many mid-market orgs carry through their vendors. Second, the month-long detection gap is where credential exposure turns into credential harvesting: every day undetected is another day of tokens and passwords flowing into the next compilation.
The Oracle PeopleSoft situation followed the same shape from the other direction. The ShinyHunters group exploited a PeopleSoft zero-day to reach organizations including the NAIC and Nissan. A single exploited enterprise application became a doorway to the credential stores and internal data behind it. The throughline is identical: exposure somewhere upstream becomes account takeover downstream, and detection lags the intrusion by weeks.
Neither of these organizations was careless in an obvious way. They were exposed through the ordinary reality of shared platforms, third-party software, and credentials that outlive their usefulness. That is the same reality your organization operates in.
What a Penetration Test Actually Validates Against Credential Exposure
This is the part the news cycle never gets to. A breach headline tells you exposure exists. It cannot tell you whether that exposure translates into a working attack path against your specific environment. That translation is exactly what a penetration test is built to determine.
A credential-focused pentest does not guess. It exercises the same techniques an attacker would, safely and with documented evidence, against your real systems. Concretely, it validates:
Authentication testing checks whether your login endpoints resist credential stuffing and password spraying, whether rate limiting and lockout policies actually trigger, and whether breached passwords are rejected at registration and reset. Session management testing checks whether stolen tokens can be replayed, whether sessions are properly invalidated on logout and password change, and whether token theft grants the persistent access that infostealers rely on. Authorization testing checks whether a single compromised low-privilege account can escalate or move laterally, which is the difference between a contained incident and a breach. Account recovery and OAuth testing checks the side doors, the reset flows and connected integrations that attackers pivot through once a primary login is defended.
The value of a test over a scan is that a scanner reports "MFA is enabled" while a pentest reports "MFA is enabled, but a stolen session token bypasses it, and here is the captured request that proves it." One is a checkbox. The other is evidence you can act on and hand to an auditor.
Before any of that, the test has to know what to point at. Credentials get replayed against your entire external footprint, not just the login page you remember. Mapping that footprint is where scoping starts, and you can begin building the picture yourself with our subdomain finder to enumerate the external hosts an attacker would spray against, and the OWASP risk calculator to rank which exposed logins carry the most damage if they fall.
How to Scope a Pentest for Credential Exposure
Turning breach anxiety into a scoped test is a short, concrete process. The aim is to make sure the test exercises the paths credential exposure actually opens, rather than a generic checklist that skips the parts that matter here.
Run through this scoping checklist before you approve any statement of work:
A test scoped this way answers the question the breach headline provoked. It replaces "are we exposed?" with a documented, prioritized list of where an attacker with stolen credentials actually gets in, and where they hit a wall.
Turning Breach News Into a Decision
The 24 billion record dump, the KDDI breach, and the PeopleSoft exploit are not three separate stories. They are the same story told three times: credentials leak somewhere upstream, attackers replay them downstream, and detection lags the intrusion by weeks. Your organization sits at the downstream end of that pipe whether or not your name ever appears in a dump.
Reading the headlines does not change your exposure. Testing does. A penetration test scoped for credential exposure is how you convert an anxious question into evidence you can take to a board, an auditor, or a budget conversation. It tells you not that exposure exists in the abstract, but whether the specific credentials floating around out there open a working path into your specific systems, and it hands you the reproduction steps to close each one.