Report
Breaches loaded into Have I Been Pwned, July to September 2026
The service loaded fewer breaches from July to September 2026 than in either earlier quarter of the year, and the email addresses in every one of them joined the lists used for phishing and password spraying. Nine months in, the year has already loaded more breaches than the whole of 2025.
- Breaches added 1 Jul to 30 Sep 2026, read 11 Nov 2026
- Published 11 Nov 2026
- PDF, 6 pages, 245 KB
- BS-RPT-15, version 1.0
Executive summary
Have I Been Pwned loaded 25 breaches between 1 July and 30 September 2026, covering 162,630,114 accounts, or 162.6 million in round figures. July carried 7 breaches and 89,879,195 accounts, August 11 breaches and 30,199,366 accounts, and September 7 breaches and 42,551,553 accounts.
From 1 January to 30 September 2026 the service loaded 104 breaches covering 531,949,423 accounts; in the whole of 2025 it loaded 91 breaches covering 2,877,214,727 accounts. Nine months of 2026 brought 13 more breaches than the whole of 2025 and 18.5 per cent of that year’s accounts.
Every one of the 25 breaches exposed email addresses; 2 of them exposed passwords as well, covering 23,417,285 of the 162,630,114 accounts, and the other 23 exposed no password. Passwords were among the exposed data in 9 of the 32 breaches loaded from January to March 2026, covering 51,475,355 accounts, and in 9 of the 47 loaded from April to June 2026, covering 61,596,500 accounts. A quarter with few password lists still feeds the attacks a small firm meets most often. A list of working email addresses is what a phishing campaign is sent to, and it is the list a password spraying run works through, trying one common password against every address on it.
The largest breach loaded in the quarter held 55,282,226 accounts, 34 per cent of the quarter’s total; the average breach held 6.5 million. One large breach can carry a third of a quarter’s accounts, and the many small ones carry the addresses of staff who signed up to a supplier portal, a conference or a trial with their work address.
- Search your domain on the service each quarter and read which staff addresses appear in which breaches, and what each breach exposed.
- Put phishing-resistant multi-factor authentication on email and remote access, so a guessed or reused password is no longer enough to sign in.
- Block common and breached passwords at the point they are set, which is what defeats a spraying run.
Report
The figures
Accounts loaded each quarter of 2026, and the accounts in breaches that exposed passwords
Accounts in the breaches loaded each month, July to September 2026
What an address list does without a password
A list of addresses with no passwords is the raw material for two attacks. The first is phishing: the list tells an attacker which addresses are live, and the other data in the breach, a name, a phone number, a supplier relationship, makes the message read as genuine. The second is password spraying: software tries a handful of the most common passwords against every address on the list, slowly enough to stay under the lockout threshold, and keeps the sign-ins that work.
Spraying works against accounts whose password is a season and a year, the firm’s name with a number, or the default a new starter was given and never changed. Blocking those passwords at the point they are set, and blocking every password in the service’s breached password list, takes the attack’s whole wordlist away. Phishing-resistant multi-factor authentication on email and remote access closes the rest, because a correct password alone no longer signs in.
The service flagged 4 of the 25 breaches as sensitive, 2 in August and 2 in September; a sensitive breach is left out of every public search and is shown only to the verified owner of the address or of the domain. The firm sees those breaches only in a verified domain search. Read them quietly, with the person, and only to the extent of changing the password and checking the account.
What to do
- Verify your domain with the service, run the domain search and keep the result with the date it was run.
- Sort the result by data class: ask the reuse question for every address in a breach that exposed passwords, and tell each staff member which of their details are out.
- Turn on the service’s notification for your verified domain, and name the person who reads each notice and acts on it.
- Block common and breached passwords at the point they are set, through your identity platform or the password manager.
- Enforce phishing-resistant multi-factor authentication on email, remote access and every system that holds client information, and keep a dated list of the accounts excluded from it.
- Watch sign-in logs for many failed sign-ins spread across many accounts from one source, which is what a spraying run looks like.
- Close the accounts of departed staff and the shared mailboxes nobody owns; they carry the oldest passwords and appear in the oldest breaches.
We run credential exposure monitoring for clients, reading each new load against their domains and acting on the addresses that appear, and we roll out multi-factor authentication and password managers across a firm with the exceptions named and closed. A firm that wants the first search done and the controls in place can engage us for both.
Method
The figures come from the public breaches feed the service publishes. For each breach it holds, the feed gives the date the breach was added, the number of accounts, the kinds of data exposed (the data classes) and two flags, verified and sensitive. We read the feed on 11 November 2026, when the most recent breach had been added on 3 November 2026, took every breach whose added date falls between 1 July and 30 September 2026, grouped them by month and summed their accounts. The two earlier quarters of 2026 and the whole of 2025 were counted from the same read, the same way.
The added date is the day the service loaded the breach. The breach itself may be months or years older; the load date marks the day the exposure became searchable, and the addresses in it had usually been circulating before then. A breach is counted as exposing passwords when its data classes list passwords, in any form the source held them; a breach that exposed only a hint, a security question or a phone number is not counted that way.
Accounts are counted per breach, as the service counts them: the number of unique email addresses it loaded from that source. An address in two breaches is counted twice. No breach is named, because what matters to a firm is whether its own staff appear, and the domain search answers that directly.
Read the data classes, as well as the count
A verified domain search lists every address on the domain the service has seen, the breaches each appears in and the data classes each breach exposed. Sort the result by data class. An address in a breach that exposed passwords needs the question of reuse asked and answered: was that password, or a variation of it, ever the office password. An address in a breach that exposed only names, addresses and phone numbers needs a different answer, because that data is what makes a phishing message or a call to the helpdesk convincing. Tell the staff member which details are out, so the next message that quotes them is read with suspicion.
The service also notifies a verified domain when one of its addresses appears in a new load. A firm that turns that on, and names the person who reads the notice, hears about each exposure in the week it becomes searchable.
BS-RPT-15, published 11 Nov 2026
The full report, as a PDF
PDF, 6 pages, 245 KB. Breaches added 1 Jul to 30 Sep 2026, read 11 Nov 2026.
More reports
Report
Known exploited vulnerabilities, July to September 2026
Additions dated 1 Jul to 30 Sep 2026, read 11 Nov 2026 · PDF, 7 pages, 240 KB
Report
Security events by hour: what our monitoring sees
Measured 26 Oct 2026, 00:45 AEST · PDF, 6 pages, 210 KB
