A publicly exposed Elasticsearch database gave anyone with a web browser free access to 24 billion stolen credential records in June 2026, according to research Cybernews published on June 12. No login. No password. Just an open port and a search bar.
The database held more than 8.3 terabytes of data: usernames, email addresses, plaintext passwords, and the exact web addresses where each credential pair worked. Researchers found it, verified the numbers, and watched it disappear from public view by June 15 — a timeline Israel Defense independently corroborated, reporting that access to the exposed instance had been locked down that same day. The data inside had already been circulating in criminal channels for months, and taking one exposed server offline did nothing to stop the pipeline that filled it — Proofpoint confirmed as much in September 2026, reporting that all 24 billion records were still actively circulating among criminals long after the original server went dark.
This wasn’t a single company’s breach. It was closer to a warehouse inventory: 36 separate sources of stolen logins, most scraped from malware-infected devices and traded across more than 30 Telegram channels, compiled into one searchable index. Researchers who track breach compilations called it one of the largest credential databases ever left exposed online. Whether it beats the 2024 “Mother of All Breaches” on raw record count is almost beside the point. What makes this leak worse is what’s attached to each password: a link telling an attacker exactly where to use it.
- 24 billion credential records exposed, each paired with a username, plaintext password, and the exact login URL it worked on
- 8.3+ TB of data sitting in an Elasticsearch database that required no login to browse
- 36 distinct sources compiled into one searchable index, most traced to Telegram credential-trading channels
- Found by Cybernews on June 12, 2026; taken offline June 15, 2026
- As of September 2026, the server’s operator still hasn’t been identified, and Proofpoint reports all 24 billion records remain in active circulation despite the takedown
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Cybernews Found Inside the Exposed Server
Cybernews researchers found the database while scanning for open, unauthenticated instances of Elasticsearch, a search and analytics tool that companies, and criminal groups, use to index huge volumes of data quickly. This particular instance required no credentials of its own to browse. Anyone who found the IP address could query 24 billion records the same way an analyst might query a corporate log server.
The team verified the total record count multiple times before publishing, given how easily leak databases can be padded with duplicates or junk entries. Even accounting for that caution, this ranks among the largest single collections of stolen credentials ever found sitting in the open, alongside the 26-billion-record “Mother of All Breaches” compilation that researcher Bob Dyachenko and Cybernews uncovered in January 2024, and the 16-billion-record credential mega-leak Cybernews itself first flagged across 30 exposed datasets in June 2025 and detailed further that July. Decryption Digest later confirmed that same 16-billion-record trove was still being actively bought and sold across 30 dark web databases as recently as May 2026, a reminder that a leak’s discovery date rarely marks the end of its useful life for criminals.
The server went dark within three days of Cybernews’ June 12, 2026 discovery, going dark on June 15 — a timeline Israel Defense separately reported, noting that access to the exposed instance had been secured by that date. Nobody has claimed ownership of it, and Cybernews said the operator’s identity remains unknown. That’s typical for this kind of exposure. The database likely belonged to a criminal marketplace, a log-reselling operation, or an aggregator tool built to make stolen credentials searchable for buyers, not a legitimate business that simply left the door open, as detailed in Malwarebytes’ write-up of the leak.
The Exposure Window: Why Three Days Undersells the Real Timeline
Cybernews found the exposed server on June 12, 2026, and it went dark by June 15, a three-day window that sounds almost responsible by industry standards. Compare that to breaches that sit exposed for months before anyone notices. But the three-day figure measures the wrong window entirely.
By the time researchers found this particular Elasticsearch instance, the data inside it had already been circulating in criminal channels for months. The database wasn’t the origin of the exposure. It was a snapshot of an ongoing criminal supply chain, one node in a longer pipeline that started with infostealer malware harvesting individual browsers, moved through Telegram channels trading logs in smaller batches, and ended with someone compiling 36 of those sources into a single searchable index. Taking that index offline on June 15 didn’t touch any of the earlier steps in the chain.
That’s the uncomfortable math behind most exposed-database stories. Three days measures how long this particular aggregation point stayed visible to researchers, not how long the underlying credentials had already been available to criminals. A password that surfaced in this database in June could have been sold, traded, or used months earlier in a Telegram channel or a private marketplace that never made headlines. The useful question isn’t how fast the server got taken down. It’s how long the password inside it was already circulating before it landed somewhere researchers could find it.
As of September 2026, nobody has stepped forward to claim the server, and Cybernews’ original assessment, that the operator’s identity remains unknown, still holds more than three months later. Proofpoint’s own review that same month found the underlying credentials hadn’t gone anywhere either: all 24 billion records remained in circulation among criminal buyers even after the database itself was taken offline.
Breaking Down the 8.3 Terabytes: Where the Data Came From
The database wasn’t one leak. It was 36 of them, stitched together. More than 30 of the 36 sources traced back to Telegram channels, the platform that has become the dominant marketplace for stolen data since messaging-app-based cybercrime took off in the early 2020s.
Most of the volume, more than 22.6 billion records — a figure The High Street Journal’s own review of the dataset also reported — came from entries researchers labeled simply as “collections,” generic aggregated dumps without one clear origin. The smaller categories tell a more specific story. Roughly 260 million records traced to Telegram channels using some variation of the name “Darkside,” 150 million came from what researchers labeled “local database dumps,” and 146 million were tagged “breach compilation combo,” the industry term for recycled credential lists assembled from older leaks, according to Security Affairs’ breakdown of the dataset.
Zoom out from those individual buckets and a different pattern shows up. Broader reporting on the dataset attributes roughly 1.7 billion records, a figure that folds in the 260-million-record Darkside cluster, to Telegram channels dedicated specifically to hacking and credential trading, as opposed to the 22.6 billion parked in the catch-all “collections” category. That distinction matters more than it sounds. A record sitting in an unlabeled collections dump could have come from almost anywhere. A record traced to a named, active hacking channel points to a specific piece of criminal infrastructure that’s still running and still trading.
A few entries stood out as evidence of just how indiscriminate infostealer malware can be. The database contained more than 17,000 records referencing CVE vulnerability IDs paired with GitHub links, plus over 5,200 logs pulled from breach-news articles and roughly 2,900 logs of cybersecurity social media posts. The malware behind this data didn’t just steal banking logins. It scraped browser history and saved credentials from security researchers’ own machines, proof that researchers are just as capable of clicking the wrong download link as anyone else.
Every record included the same core fields: username or email, plaintext password, the login URL it belonged to, and metadata pointing back to its source.
Why the Source Breakdown Matters More Than the Headline Number
The 24-billion figure is the headline, but it’s the wrong number to focus on when the goal is deciding what to actually do about this leak. Most of that total, the 22.6 billion records filed under “collections” — a figure The High Street Journal’s own analysis of the dataset also arrived at — is functionally unattributed. Researchers can say it came from infostealer malware in general. They can’t say which strain, which campaign, or which criminal group is actively trading it right now. That’s archival data in the loosest sense: real and dangerous, but hard to act on.
The channel-attributed slice is smaller and more useful. The roughly 1.7 billion records tied to hacking-focused Telegram channels, including the 260-million-record Darkside cluster, point to specific, ongoing distribution points rather than a static dump. Security researchers who monitor those channels can watch what gets posted, track which domains show up most often, and flag active campaigns before the stolen credentials get folded into the next mega-database. That’s the difference between forensics and threat intelligence: one explains what already happened, the other flags what’s happening right now.
It’s also why comparing this leak to something like the 2024 Mother of All Breaches on record count alone misses the point. MOAB was almost entirely archival, a compilation of compilations. This database’s channel-sourced records look more like a live feed. For a security team deciding where to spend limited monitoring budget, a 1.7-billion-record slice tied to active criminal channels is a better lead than a 22.6-billion-record slice with no clear source. Scale matters less than traceability once a leak gets this large.
None of this makes the “collections” portion of the database safe to ignore. It just means the response looks different: broad password resets and breach-monitoring checks for the bulk of the data, and more targeted threat-intelligence monitoring for the channel-sourced slice that’s still actively feeding new criminal activity.
Run the actual percentages and the imbalance gets sharper. The 22.6 billion collections records account for roughly 94% of the entire 24-billion-record total, while the 1.7 billion channel-attributed records, including the 260-million-record Darkside cluster, work out to close to 7% (the two slices overlap slightly, since Darkside is a subset pulled from the channel count rather than a separate bucket). Put another way: for roughly every 100 records in this database, about 94 come with no identifiable origin beyond “infostealer malware, somewhere,” and 6 or 7 point back to a named, currently active distribution channel that researchers can actually watch.
The smallest categories put that scale in perspective. The 17,000 CVE-linked records, 5,200 breach-news logs, and 2,900 cybersecurity-social-media logs that stood out as curiosities add up to roughly 25,100 entries combined, well under 0.001% of the 24 billion total. They’re statistical noise next to the headline figure. What makes them worth mentioning is what they represent: infostealer malware doesn’t distinguish between a bank login and a security researcher’s GitHub token. Any unprotected device is a candidate for the next version of this database, regardless of who uses it.
How a Database This Size Ends Up Exposed to Anyone With a Browser
Elasticsearch and similar NoSQL tools ship without authentication turned on by default. That’s fine for a developer testing something locally. It becomes a liability the moment that same instance gets deployed to a public cloud server and nobody remembers to lock it down, a pattern TechRepublic’s reporting on the leak flagged as a recurring failure across similar incidents.
Elasticsearch listens on port 9200 by default, and that default is part of why exposures like this keep happening. Security researchers, and criminal groups, routinely scan the entire public IPv4 address space looking for that port using tools like Shodan and Censys, precisely because so many instances get deployed to cloud servers with authentication left switched off. Finding one exposed database this size doesn’t require a sophisticated intrusion. It requires knowing which port to check and enough patience to work through a scan’s results.
This is not a new failure mode. Researchers have been finding exposed Elasticsearch, MongoDB, and Kibana instances loaded with stolen data for years, and the 2024 Mother of All Breaches turned up the exact same way, through an open, unsecured server that anyone could query without logging in. What’s changed is the scale and the sophistication of what gets loaded into these databases. Criminal groups now treat stolen-credential aggregation as its own product line, building searchable, indexed tools out of the same open-source software that large companies use to power internal search systems.
The irony is hard to miss. The infrastructure criminals use to organize stolen data is often less secure than the infrastructure their victims used to store it in the first place.
Auditing Your Own Infrastructure Before It Becomes the Next Headline
Everything about how this particular Elasticsearch instance got found applies just as easily to a legitimate company’s infrastructure as it does to a criminal aggregator’s. The same scanning techniques Cybernews used, and the same ones criminal groups use every day, work against any organization that has spun up a database on a public cloud server and forgotten to lock down the port.
Security teams can run a version of that same scan against their own environment before an outsider does it for them. Shodan and Censys, the two scanning platforms described above, both let an organization search by its own IP ranges or ASN to see what’s publicly reachable, including any Elasticsearch, MongoDB, or Kibana instance an internal review missed. A quarterly external scan costs a fraction of what a breach response does, and it’s the same kind of check that would have caught the misconfiguration behind this leak, and behind the 2024 Mother of All Breaches before it, before either became a headline with a different company’s name attached.
Cloud misconfigurations like an open Elasticsearch port rarely start as a deliberate decision. They start as a default nobody changed: a developer spins up a test instance to prototype something, authentication stays off because it’s faster to iterate without it, and the instance either never gets torn down or gets promoted toward production without anyone revisiting the original settings. Cloud providers have added guardrails against exactly this pattern, security group templates that block public access by default, but those guardrails only hold if a team hasn’t manually overridden them to get something working faster under deadline pressure.
The fix has less to do with any single tool and more to do with ownership. Every database instance needs a named owner responsible for confirming authentication is switched on before it goes anywhere near a public IP address, plus an asset inventory that flags any instance nobody has claimed. That inventory gap is what let this leak’s underlying database sit exposed long enough for Cybernews to find it, and closing it is what keeps the next 24-billion-record headline from carrying a different company’s name.
Lumma, Vidar, RedLine: The Malware Behind the Logs
Every record in this database started the same way: a piece of infostealer malware sitting quietly on someone’s computer, harvesting whatever the browser had saved.
The malware families most commonly linked to logs like these are Lumma Stealer, Vidar, RedLine, and Raccoon, plus a rotating cast of variants sold as malware-as-a-service on the same Telegram channels that distribute the stolen logs afterward. Vidar had a particularly strong run at the start of 2026, accounting for more than 73% of infected hosts tracked across the first two months of the year, according to industry telemetry cited by SecurityWeek. Lumma, meanwhile, kept operating through 2026 despite two separate law enforcement takedown efforts, a resilience that shows how cheap and disposable this malware infrastructure has become for the people running it.
These tools don’t need to trick a user into typing a password into a fake login page. They wait for a browser to autofill one, then quietly copy it, the saved session cookie, and whatever else sits in the browser’s storage, before sending it all to a remote server. Infection usually starts somewhere mundane: a cracked copy of a paid app, a fake game cheat, a browser extension that promised something it didn’t deliver.
From an Infected Laptop to a Supply-Chain Breach
The path from “employee downloads something they shouldn’t” to “company gets breached” isn’t hypothetical. Researchers have documented at least one case this year that traces the whole chain start to finish: an employee at AI startup Context.ai downloaded Roblox cheat software onto a work device and got infected with Lumma Stealer. The stolen credentials from that single infection were later connected to unauthorized access that contributed to breaches at Vercel and Mercor.
That’s the mechanism worth sitting with. A cheat tool built for a video game, a personal device blurred into a work one, and a stolen session cookie became the opening move in a multi-company incident. No phishing email. No brute-force attack. Just a browser that remembered a password it shouldn’t have needed to.
Service Accounts and Deploy Keys: The Part of This Leak Most Advice Skips
Look back at the illustrative log entry a few sections up. Two of its three fields aren’t a personal inbox or a shopping account. One is a corporate GitHub organization tied to a service account, [email protected]. The other is a VPN portal. That mix isn’t included for color. Researchers who study infostealer logs see this pattern constantly: browsers on developer and IT-admin machines save credentials for source control, CI/CD pipelines, and cloud consoles right alongside a personal inbox login, and the malware harvests all of it in the same pass. It doesn’t sort a machine’s password from a human’s.
That indifference shows up in the smaller numbers already pulled from this database. The more than 17,000 records referencing CVE identifiers paired with GitHub links, plus the 5,200 breach-news logs and 2,900 cybersecurity-social-media logs, all trace back to the browsing habits of security-adjacent professionals. Cybernews didn’t break the 22.6 billion-record “collections” bucket out by account type, so there’s no verified count of how many entries beyond those curiosities are service accounts, API keys, or deploy credentials rather than personal logins. What the illustrative pattern does establish is that infostealer malware doesn’t pause to check whether a saved credential belongs to a person or a pipeline before it gets bundled into a database like this one.
That distinction matters because machine credentials tend to be more dangerous than the personal ones getting most of the attention. A service account usually carries standing privilege scoped for automation, not a single login session, and nobody is personally watching it the way a person watches their own inbox for a “new sign-in” alert. These credentials get shared across a team, embedded in scripts and configuration files, and rotated far less often than a human is asked to change a password, because rotating a deploy key means updating every system that depends on it. A stolen personal password compromises one account. A stolen deploy key can compromise everything that account was ever allowed to touch.
The Context.ai chain described above is the clearest evidence of what that looks like in practice. A single infected laptop didn’t just expose one employee’s logins. It fed credentials into a pipeline investigators later connected to unauthorized access at two other companies. Enterprise teams that treat a leak like this one as a personal-password problem are solving half the issue.
The fix is inventory, not just rotation. Security teams need a list of which service accounts, API keys, and CI/CD secrets live in a browser’s autofill or a saved-credentials file rather than a dedicated secrets manager, then a plan for moving them somewhere infostealer malware can’t scrape on its way out. Identity vendors are already building toward this. The lifecycle platforms described in the market-impact numbers above increasingly treat non-human identities, service accounts, API keys, and workload credentials, as a distinct product category with their own rotation and monitoring rules, rather than an afterthought bolted onto human identity management.
None of that shows up in a standard breach notification, which is exactly why it gets missed. A consumer-facing alert tells a person to change a password. It has no mechanism for telling a DevOps team to rotate a deploy key that a browser saved months ago and nobody has thought about since.
Why Credentials Paired With Login URLs Beat Old-Style Password Dumps
Old-school breach dumps forced attackers to guess. A leaked password list from one hacked forum told you nothing about where else that person used the same password, so criminals ran automated credential-stuffing attacks, firing stolen username-password pairs at hundreds of unrelated websites and hoping for a match.
Infostealer logs remove the guesswork. Each entry already comes tagged with the exact site the credential unlocks, because the malware captured it directly from a real login event. A stolen password isn’t just a password anymore. It’s a password plus a map.
Here’s roughly what one of these log entries looks like once malware has captured it, with the specifics scrubbed for this example:
[INFOSTEALER LOG ENTRY - ILLUSTRATIVE FORMAT]
URL: https://mail.example-corp.com/owa
USER: [email protected]
PASS: ********
---
URL: https://github.com/example-corp
USER: [email protected]
PASS: ********
---
URL: https://vpn.example-corp.com/portal
USER: [email protected]
PASS: ********Multiply that by 24 billion, and the practical difference between a credential leak and a targeted attack starts to disappear. An attacker doesn’t need to breach a company. They need to search a database for its domain name.
Credential Stuffing Attack Anatomy: From Leaked Record to Account Takeover
Knowing a database like this one exists is different from understanding what happens after someone downloads it. The path from a raw log entry to a compromised account follows a fairly consistent pattern, and nearly every step in that pattern exists specifically to get around the login defenses most companies already have in place.
Attackers rarely test stolen credentials by hand at this scale. Automated tools load lists of URL-username-password triples and fire login attempts in bulk, and because every record in this database already carries the correct login URL, that tooling skips a step older credential-stuffing campaigns needed: there’s no reason to test a stolen password against a thousand unrelated sites when the log entry already says which one it unlocks. What used to be a guessing game becomes a lookup.
Two defenses make that automation harder, and both show up in how a leak like this typically gets used. Rate limiting flags an unusual volume of login attempts from a single IP address, so attackers spread requests across residential proxy networks, pools of addresses tied to real home internet connections that make each attempt look like an ordinary user rather than a script running out of a data center. CAPTCHA challenges get routed to low-cost human-solving services built to clear that hurdle for a fee. Neither defense is worthless; both simply raise the cost of an attack instead of stopping it. At a scale of 24 billion records, even a fractional success rate still produces a meaningful number of compromised accounts.
The split between this database’s two main categories matters again here. The 22.6 billion “collections” records, roughly 94% of the total, are the more likely candidates for broad, automated stuffing runs aimed at whatever login page the URL field points to. The 1.7 billion records tied to active hacking channels, the remaining slice, are more likely to get picked out by hand, since a credential still circulating on a live Telegram channel signals it’s fresh enough to be worth individual attention rather than bulk automation. Security teams that monitor those channels directly, instead of waiting for the next public database to surface, tend to catch targeted attempts earlier.
Detection tools built to catch this pattern look for the signature of automation rather than any single failed login: a spike in attempts against one endpoint, missing browser-fingerprint details a real session would carry, or a password success rate that’s statistically implausible for a human typing from memory. Bot-mitigation vendors have built entire product lines around catching exactly this pattern, a category that keeps growing alongside the infostealer-fed databases feeding it.
How the Leak Stacks Up Against History’s Biggest Breach Compilations
Raw record counts don’t tell the whole story. Data quality, duplication, and how fresh the credentials are all matter more than the headline number, but the count is still useful for scale. Here’s how the June 2026 database compares with the breach compilations that came before it.
| Breach Compilation | Year Found | Records | Data Size | Nature of Data |
|---|---|---|---|---|
| RockYou (original breach) | 2009 | 32 million | Not disclosed | Single-site plaintext passwords |
| COMB (Compilation of Many Breaches) | 2021 | 3.2 billion | Not disclosed | Aggregated breach dump |
| RockYou2024 | 2024 | ~9.95 billion unique passwords | Not disclosed | Password wordlist compilation |
| Mother of All Breaches (MOAB) | 2024 | 26 billion | 12 TB | Aggregated PII from thousands of past breaches |
| June 2026 Elasticsearch leak | 2026 | 24 billion | 8.3+ TB | Live infostealer logs from 36 sources, credentials paired with URLs |
By raw count, this database sits just behind MOAB and ahead of RockYou2024. What separates it from both is composition. MOAB and RockYou2024 were largely archival, built from years of recycled breach data. The June 2026 database skewed toward live infostealer output, credentials still tied to working login pages rather than passwords from sites that may have long since forced a reset.
The Compilation Growth Curve: Why 24 Billion Didn’t Break the Record
Line up the last five years of these compilations and a pattern shows up. COMB held 3.2 billion records in 2021. RockYou2024 pushed past 9.9 billion unique passwords. MOAB reached 26 billion in January 2024. This database landed at 24 billion in June 2026, roughly 2 billion short of MOAB’s total. As of September 2026, more than fourteen weeks after Cybernews’ discovery, that gap hasn’t closed — and Proofpoint’s September review found the 24 billion records were still circulating in criminal channels, untouched by the June takedown. Every earlier entry on that list broke the record set by the one before it. This is the first one that didn’t.
That plateau probably says more about duplication than about criminals losing interest. This database, like the ones before it, drew from 36 separate sources rather than one clean breach, and infostealer malware keeps re-harvesting the same infected, and reinfected, devices over months. A password captured off a laptop in March and the same password captured again in May from that same still-infected machine both count as separate entries in a raw total. Cybernews said it verified the count specifically to screen out duplicates and junk entries, which makes 24 billion a more conservative figure than some past compilations, but verification doesn’t mean every one of those 24 billion records points to a person who has never shown up in a leak before. At this scale, the total measures how much infostealer malware is actively running at least as much as it measures how many new victims exist.
Inside 2026’s Infostealer Economy, By the Numbers
The 24 billion credentials leaked from this single database sound almost abstract until they sit next to the rest of 2026’s numbers. Breachsense’s own corpus swelled to 58 billion records after tacking on 1.56 billion freshly stolen credentials pulled from 2.85 million infected machines during 2025 alone, according to an April 2026 report, and SpyCloud’s recaptured identity datalake climbed to 65.7 billion records in 2026, a 23% jump from 53.3 billion the year before. Cyberfence Platform put the number of stolen credential pairs actively circulating underground even higher, more than 24 billion as of July 2026, drawing on data from BioProfileMe. The pace hasn’t let up since: BreachSense reported that in August 2026 alone it indexed 133 million credential records, including nearly 58 million distinct username-password pairs, harvested from just over 1.2 million newly infostealer-infected machines in that single month. Credential theft isn’t a side effect of cybercrime anymore. It’s the main event.
| Metric | Figure | Source |
|---|---|---|
| Records in the June 2026 exposed database | 24 billion | Cybernews |
| Size of the exposed database | 8.3+ TB | Cybernews |
| Distinct sources compiled into the database | 36 (30+ Telegram channels) | Cybernews |
| Credentials stolen by infostealers in 2025 | 1.8 billion across 5.8 million devices | Shattered.io |
| Compromised credentials circulating on criminal markets, 2025 | 2.86 billion | KELA State of Cybercrime 2026 |
| Share of infected hosts tied to Vidar, Jan-Feb 2026 | 73%+ | Industry telemetry, via SecurityWeek |
| MFA-bypass breaches attributed to session-token theft | 80% | Microsoft 2025 Digital Defense Report |
| Global information security spending, 2026 | $248.9 billion | Gartner, via Axis Intelligence |
Shattered.io’s research put 2025’s infostealer haul at 1.8 billion credentials across 5.8 million infected devices, an increase the firm described as an 800% surge over prior years. KELA’s State of Cybercrime 2026 report separately tracked 2.86 billion compromised credentials actively circulating on criminal markets in 2025 alone, drawn from malware logs, breach databases, and underground marketplaces combined. SpyCloud’s own 2026 compromised-credential analysis recaptured 5.3 billion credential pairs and 8.6 billion session cookies from 2025 activity alone, while Specops separately tallied 6 billion malware-stolen passwords pulled from logs and leaks by 2025 in its own credential statistics review. Microsoft’s own 2025 Digital Defense Report tied 80% of multi-factor-authentication bypasses to stolen session tokens rather than cracked passwords, a figure worth sitting with. MFA still blocks plenty of attacks, but a stolen session cookie can let an attacker skip the login prompt entirely.
The Session-Token Blind Spot: Why Password Resets Alone Won’t Stop These Attacks
The standard advice to “change your password” assumes the attacker still needs the password. Increasingly, they don’t. When infostealer malware harvests a browser, it copies more than whatever sits in the autofill fields. It also grabs active session cookies and authentication tokens, the small pieces of data a browser holds onto after a successful login so a user doesn’t have to re-enter credentials on every page. An attacker who steals that token can load it into their own browser and walk into an already-authenticated session directly, no password or MFA prompt required, because as far as the server is concerned, the session was never interrupted.
That’s the mechanism behind the 80% figure in Microsoft’s 2025 Digital Defense Report cited above: most of the MFA bypasses researchers tracked didn’t involve cracking a password or defeating a one-time code. They involved a stolen session token that skipped the authentication step entirely. A password reset doesn’t touch that problem. Rotating a password stops an attacker trying to log in from scratch. It does nothing to a session that’s already open, because the token tied to that session typically stays valid until it expires or someone explicitly revokes it.
That’s why the response to a leak like this one should include a step that consumer-facing breach notifications routinely skip: revoke active sessions, not just passwords. Most major platforms bury this option somewhere in account security settings, often labeled “sign out of all devices” or “manage active sessions.” Using it forces every open session, including one an attacker might be quietly holding onto, to re-authenticate. On the enterprise side, shortening default session lifetimes and requiring re-authentication for sensitive actions, even for users who are already logged in, closes the same gap. Neither step shows up in a typical breach-notification email, and both matter more than the password change that does.
A Second Warning Sign: Check Point’s VPN Zero-Day
The credential database wasn’t the only story reinforcing this point in June 2026. Days earlier, Check Point disclosed CVE-2026-50751, a critical authentication-bypass flaw in its VPN products carrying a CVSS score of 9.3. The bug let an unauthenticated attacker establish a full VPN session without a valid password, the result of a logic flaw in how the software validated certificates, as Help Net Security detailed shortly after disclosure.
Forensic evidence showed attackers had quietly used the flaw since May 7, 2026, more than a month before it became public. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on June 9 and gave federal civilian agencies until June 11 to patch or isolate affected systems, a three-day window under Binding Operational Directive 22-01. At least one confirmed case involved a Qilin ransomware affiliate using the flaw for post-compromise access.
Different bug, different vendor, same underlying failure. Authentication that’s supposed to keep unauthorized users out didn’t. Whether it’s a stolen password with a matching URL or a certificate-validation flaw that skips the password check altogether, the result for a defender looks the same: someone gets in who shouldn’t.
Market Impact: Passkeys, Identity Vendors, and Security Budgets
Global spending on information security is on track to hit $248.9 billion in 2026, according to Gartner figures compiled by Axis Intelligence. Identity and access management remains one of the fastest-growing categories within that budget. Two sub-categories in particular, consent management and subject rights automation, are expanding at 22.1% and 16.2% respectively, well ahead of the broader IAM market’s 11.8% growth rate.
None of that spending stopped a 24-billion-record database from sitting exposed for days. That gap between budget and outcome is exactly why passwordless authentication keeps gaining ground as a policy conversation rather than just a vendor pitch. Passkeys built on FIDO2 standards bind a credential to a specific device and domain, which makes them useless to an attacker even if they somehow end up in a database like this one. A stolen passkey doesn’t work anywhere else, unlike a stolen password.
Identity security vendors, credential-monitoring services, and companies selling breach-exposure checks are the more immediate beneficiaries. Enterprise security teams facing a leak of this size tend to reach first for whatever tool tells them fastest whether their own domain shows up in the data, then worry about longer-term architecture changes second.
Competitive Landscape: How Security Vendors Are Responding
Endpoint detection vendors have leaned hard into infostealer detection over the past year, since catching the malware before it phones home is the only reliable way to stop a credential from reaching a database like this one in the first place. Products from CrowdStrike, Microsoft Defender, and SentinelOne now ship with behavioral detections aimed at browser-credential-harvesting malware rather than relying solely on signature matching, which infostealer authors update too quickly for signatures to keep pace with anyway.
The leak also lands in a year already crowded with credential-driven incidents. One Medical’s breach, claimed by ShinyHunters, and a similar breach at Match Group both trace back to unauthorized access rather than a software exploit. So did the breach at Klue, which started with a single credential that had gone unrotated for four years. None of these are infostealer stories specifically, but they share the same root cause as the 24-billion-record database: credentials that should have been rotated, monitored, or replaced with something phishing-resistant, and weren’t.
That pattern is pushing identity vendors to market themselves less as password managers and more as full lifecycle platforms, tools that flag stale credentials, force rotation on a schedule, and detect when a login pattern looks like it’s coming from a stolen session rather than the real user.
How to Actually Check Whether Your Credentials Are Exposed
Checking exposure sounds simple: type an email address into a lookup tool and see what comes back. The mechanics behind that lookup matter more than they seem to. Reputable checkers hash an email address and compare it against hashed entries in their index, and those indexes keep expanding: HaveIBeenPwned alone folded in 1.96 billion emails and 1.3 billion passwords sourced from the Synthient corpus in November 2025. They can confirm an address appears in a given dataset without displaying the plaintext password attached to it, both to protect users from a tool that would otherwise hand out working passwords to anyone who types in an email, and because publishing plaintext credentials at scale would recreate the exact exposure the tool exists to warn about. A hit confirms an address was captured somewhere. It doesn’t say which password, which site, or how recently, without a paid or ownership-verified tier layered on top.
A clean result carries less weight than it looks like it should, too. This database compiled 36 separate sources, and no single checker ingests every criminal Telegram channel or infostealer log the moment it starts circulating. A lookup tool reflects whatever snapshot it last indexed, not the full, constantly updated pipeline described earlier in this piece. An address that comes back clear today could still surface in the next compilation, especially if the device behind it is still infected and still feeding a log somewhere. That gap matters more for organizations than individuals. A security team checking a handful of executive inboxes learns little about whether the company’s broader domain, including service accounts and shared mailboxes, shows up anywhere inside the 22.6-billion-record “collections” bucket that Cybernews never broke out by organization. Domain-wide monitoring, not a one-time personal lookup, is what actually answers that question.
For individuals, running an address through two independently maintained breach-monitoring tools is more useful than trusting a single service’s index, since coverage varies by which sources each one has ingested. For enterprises, the more reliable signal isn’t a lookup at all. It’s outbound telemetry: a security team that sees authentication attempts against its own VPN or SSO portal using credentials that were never issued, or logins from IP ranges and devices that don’t match an employee’s normal pattern, is watching this database’s contents get used in real time. That catches an active attack whether or not the specific credential involved ever surfaces in a public checker. Treating exposure as a single lookup misses the point. The credentials in this leak will keep getting tested against real login pages long after the headline fades.
What Security Teams and Individuals Should Do Now
For Enterprise Security Teams
Security teams don’t need to identify every one of the 24 billion records to act on this. A few steps matter more than a full audit: force password resets for any domain that shows exposure in breach-monitoring tools, invalidate active session tokens rather than just rotating passwords, since stolen cookies bypass password changes entirely, and prioritize phishing-resistant MFA or passkeys for anything internet-facing. Reviewing endpoint logs for infostealer indicators, unusual browser-data access, unexpected outbound connections to unfamiliar domains, matters too. Catching an infection early is cheaper than cleaning up after the credentials it stole end up in the next exposed database.
For Individual Users
Individuals have fewer moving parts to manage but the same basic playbook applies. Check whether an email address turns up in reputable breach-monitoring tools, change any reused passwords immediately, and turn on multi-factor authentication everywhere it’s offered. A password manager that generates unique credentials per site limits the damage of any single exposure to one account instead of dozens. None of this is glamorous advice. It’s also the difference between one compromised login and a cascade of them.
Predictions: Where the Infostealer Economy Goes From Here
A few things look likely for the rest of 2026, based on the pattern this leak fits into.
More exposed aggregation databases will surface. Criminal groups keep building searchable tools out of stolen logs, and the underlying software, Elasticsearch, MongoDB, and similar NoSQL platforms, keeps getting misconfigured at a predictable rate. Expect at least one more billion-record exposure before the year ends.
Passkey adoption accelerates faster among large enterprises than consumer apps. The economics favor companies with the engineering resources to roll out FIDO2 support, while smaller consumer platforms lag behind, creating an uneven security landscape across the accounts an average person holds.
Initial access brokers lean further into reselling logs instead of running their own intrusions. Buying a log with a working corporate VPN credential is cheaper and faster than developing an exploit, and this database previews how commoditized that supply chain has become.
Regulatory attention on exposed cloud databases grows. Lawmakers and regulators in the US and EU have already started asking pointed questions about breach notification timelines. A database this size, sitting exposed for days with no clear owner, is the kind of story that tends to surface in the next round of hearings.
Session-token theft overtakes password theft as the primary MFA-bypass method security teams track. That extends the trend Microsoft’s research already shows. Passwords matter less when a stolen cookie skips the login screen entirely.
Frequently Asked Questions
What exactly did Cybernews find in June 2026?
An unsecured, publicly accessible Elasticsearch database containing 24 billion credential records: usernames, plaintext passwords, and login URLs, pulled together from 36 different sources of stolen data. It required no authentication to browse and was taken offline roughly three days after researchers found it, on June 15, 2026.
Is this the largest data breach in history?
Not by raw record count. The 2024 “Mother of All Breaches” held 26 billion records. But this database’s records came overwhelmingly from live infostealer malware logs paired with exact login URLs, which most security researchers consider more immediately dangerous than an older, archival compilation.
How much of the leaked data traces to active criminal channels rather than old dumps?
Roughly 1.7 billion of the 24 billion records trace to Telegram channels focused specifically on hacking and credential trading, including a 260-million-record cluster branded “Darkside.” The remaining 22.6 billion sat in a catch-all “collections” category with no single identifiable source, making the channel-attributed slice a smaller but more actionable target for threat-intelligence monitoring.
How can I check if my credentials were part of the leak?
Reputable breach-monitoring services let users search by email address to see whether their information appears in known exposed datasets. Cybernews and several security vendors updated their lookup tools shortly after the database was found.
What should I do if my information was exposed?
Change the password on any affected account right away, especially if you reused it elsewhere, and enable multi-factor authentication. If a service offers passkeys, switching to one removes the password, and the risk of it leaking again, entirely.
Does this mean my accounts were definitely hacked?
Not necessarily. Appearing in a stolen-credential database means the password was captured at some point, typically by infostealer malware on an infected device, not that every listed account has been actively broken into. It does mean the credential is available to anyone who finds or buys access to similar data.
Is multi-factor authentication still worth using if passwords are this exposed?
Yes, with a caveat. Traditional MFA blocks most password-only attacks. It’s less effective against session-token theft, the method Microsoft’s 2025 Digital Defense Report linked to 80% of MFA bypasses, since a stolen session cookie can let an attacker skip the login prompt entirely.
Who owned the exposed database?
Unknown. Cybernews said the server’s operator was never identified, which is typical for databases that appear to aggregate stolen data from multiple criminal sources rather than belonging to one legitimate organization. Proofpoint’s September 2026 follow-up found the same gap in attribution, but confirmed all 24 billion records remained in active circulation among criminal buyers months after the server itself went dark.
How is this different from a typical company data breach?
A typical breach exposes one organization’s user data through a single point of failure. This database aggregated data from 36 separate sources across many unrelated victims and platforms, closer to a criminal inventory system than a breach in the traditional sense.
Does this leak include business credentials like GitHub tokens or VPN logins, not just personal accounts?
Yes. Alongside personal email and password pairs, the illustrative record structure in this database includes service-account and infrastructure credentials, logins for source control, VPN portals, and cloud consoles pulled from the same infected browsers. Cybernews didn’t publish a specific count of business versus personal accounts within the 22.6 billion-record “collections” bucket, but the more than 17,000 CVE-linked GitHub records already documented in the dataset show infostealer malware pulls developer and IT-admin credentials with the same indifference it applies to personal logins.
