Stealer logs in the breach record: one address in five

This site's queue had this post down as "why stealer logs dominate 2025-2026 breach volume". The public breach record does not support the word dominate. Measured by addresses loaded into Have I Been Pwned during 2025 and 2026, entries flagged as stealer logs are 20.7 per cent: one address in five. The largest single entry of 2025, nearly two billion addresses, is not a stealer log at all.

That still makes them one of the most important things in the record, for a reason that has nothing to do with volume. A stealer log is not evidence that a service was breached. It is evidence that a person's computer was, and it names the websites they logged into while it was. This post counts the six flagged entries, measures their share two ways, shows why the flag undercounts, and says what a defender does differently when one of their users turns up in one.

The catalogue is metadata about breaches; it holds no addresses and no passwords, and neither does anything published here.

What a stealer log is

Have I Been Pwned's own definition is short: "Stealer logs are the result of malicious software running on infected machines that collect email addresses, passwords and the website they're entered into at login." Its API documentation adds what makes the flag different from every other one: "A breach with this flag also has the domains that appear in the logs loaded against each email address."

That third field is the whole difference. A normal breach entry says: this service lost this list. A stealer-log entry says: on some infected machine, this address and this password were typed into this website. The service in that last field did nothing wrong, and may never know.

The catalogue has a separate, older flag for malware-sourced data, with its own warning that "the risk posed to individuals in these incidents is different (their personal device may be compromised)". Nine entries carry it, including four Operation Endgame releases. None of the six stealer-log entries carries both flags; the two are applied independently.

The six entries

The catalogue retrieved on 23 September 2026 holds 1,038 entries and 17,837,211,580 loaded addresses. Six are flagged IsStealerLog.

Together they are 4.09 per cent of every address the service has ever loaded, from 0.58 per cent of its entries, and all six arrived in the last twenty-six months. Every one carries exactly two data classes, email addresses and passwords. The January 2025 entry is the one its own description calls "the launch of a new HIBP feature enabling the retrieval of the specific websites the logs were collected against".

Rows are not people

Stealer-log corpora are enormous in rows and much smaller in people, because the same infected machine logs the same credentials again and again, and the same logs are traded, merged and re-posted. Two of the descriptions state both numbers:

The Data Troll entry is the one behind June 2025's "16 billion password" headlines. The catalogue's description is blunt about it: the data "was a compilation of publicly accessible stealer logs, mostly repurposed from older leaks, with only a small portion of genuinely new material". What reached the service was 2.7 billion rows, and 109 million unique addresses. That is the number of people, and it is 0.7 per cent of the headline.

The June 2026 entry reports it the same way: "hundreds of millions of stealer log records" reducing to 56 million unique addresses, and 124 million unique passwords added to the separate Pwned Passwords list.

How big a share, measured two ways

The catalogue carries two dates per entry, and they answer different questions. AddedDate is when the service loaded the data, which is what a defender experiences as new exposure. BreachDate is the date the entry is assigned, about which the documentation warns: "Use this attribute as a guide only."

By the year the data was loaded:

By the year the data is dated:

Loaded across 2025 and 2026 together: 194 entries, 3,408,740,203 addresses, of which 703,945,513, or 20.7 per cent, are flagged stealer logs.

The one column where stealer logs are a majority is the last: of 2026-dated entries that contain passwords, 64.9 per cent of the addresses are stealer-log addresses. But that is one entry, June 2026's, set against only twelve password-bearing entries dated this year, and it says more about 2026's other breaches than about stealer logs. The typical 2026 entry is a customer database: 71 of the 83 entries dated this year contain no passwords, while 81 per cent carry names, 69 per cent phone numbers and 61 per cent physical addresses. The earlier breach-record post found the password share of each year's breaches falling to 14 per cent for 2026, and that is the same fact seen from the other side.

Why the flag is a floor, not a measure

The largest entry of 2025 is not flagged. SynthientCredentialStuffingThreatData holds 1,957,476,021 addresses, and its description says what it is: credential-stuffing lists "comprised of email addresses and passwords from previous data breaches". That is recycled breach data, the raw material of credential stuffing, and it is correctly left unflagged.

The 2024 entry TelegramCombolists is a harder case. Its description says the data contained "email addresses, usernames, passwords and in many cases, the website they were entered into" and "appears to have been sourced from a combination of existing combolists and info stealer malware". It is not flagged either, and its 361 million addresses are counted as not-stealer-log in every table above.

So the flag marks the entries the service loaded with per-address website data and classified as stealer logs. It does not mark every entry that contains stealer-derived credentials, and there is no field that would let anyone separate the stealer-sourced part of a mixed corpus. Every share on this page is therefore a lower bound on how much stealer malware contributes to the record. It is not an estimate of it, and we would not publish a "true" figure: the catalogue does not contain one.

What is different for a defender

A stealer-log hit changes the question from "was our service breached?" to "which of our users' devices is compromised?", and the answer changes the response.

• The service is not the cause. A stealer-log entry naming your login page means someone typed a password into it on an infected machine. Your password storage, your database and your perimeter are not implicated by the entry itself.
• A reset on the same machine may not help. This is reasoning from the definition rather than a measured result: if the malware captures credentials as they are typed, a new password typed into the same machine is exposed the same way. The first fix is the device, and the password reset is second.
• Look for your domain, not just your users' addresses. The API offers stealer-log lookups by email address, by email domain, and by the website domain the credentials were entered into; the June 2026 entry's description points organisations to "the stealer logs API" to see logs affecting their domain. That third lookup is the one only a stealer log can answer.
• Sessions matter as much as passwords. A machine that was capturing passwords may also have been in a position to capture a live session. This site's session tokens post covers rotation and invalidation; the defensible default after a stealer-log hit is to end the user's sessions as well as reset the password.
• Take the password out of the loop. A passkey has no typed secret for a log to record. It does nothing for an already-stolen session, which is why the point above comes first.

Limitations

• The flag undercounts, as shown above, and nothing in the catalogue measures by how much.
• PwnCount is unique email addresses loaded, not accounts, not people and not the rows in the underlying corpus. The documentation says it "is usually less than the total number reported by the media".
• Row counts are only as good as the descriptions. Two of the six state a row total; the other four do not, and none has been estimated here.
• Recent years are incomplete. Data dated 2026 that has not yet been found or loaded is not in the record, so the 2026 rows will grow.
• The catalogue is one service's view. It records what Have I Been Pwned was given and chose to load, which is a large share of what circulates publicly and not all of it.

The dataset

datasets/stealer-logs-in-the-breach-record.csv has one row per flagged entry: name, title, the dated and loaded days, unique addresses, the row count its description states where it states one, rows per address, data classes, the verified and malware flags, and its catalogue URL. It contains no email addresses and no passwords; it is built from the same public metadata as this page.

Reproducing it

code/stealer-logs-in-the-breach-record.py needs only the Python standard library and a network connection:

python stealer-logs-in-the-breach-record.py --csv stealer-logs-in-the-breach-record.csv

The share itself is two sums over the same year, with the flag as the only filter:

rows = [b for b in breaches if b[key][:4] == year]
total = sum(b["PwnCount"] for b in rows)
stealer = sum(b["PwnCount"] for b in rows if b.get("IsStealerLog"))

Swapping key between AddedDate and BreachDate is the whole difference between the two tables above. It reads the public breaches endpoint, lists the flagged entries, prints both yearly tables and the combined 2025-26 share, and writes the CSV with --csv. Run on another day it will report that day's catalogue, which is the point: when the next stealer-log corpus is loaded, the shares above will move, and the script will show by how much. The companion breach-record post covers the whole catalogue rather than one flag.