DEV Community

Ahsan Luqman
Ahsan Luqman

Posted on Originally published at aliasfleet.com on

Your address was pwned, so here is what the red screen means

A red pwned result is a filing record, not a break-in notice. Your address sits in a stolen file. I run AliasFleet, an email-alias service that gives every site its own forwarding address, so the next breach hands attackers an address you can kill.

You typed your address into Have I Been Pwned and the screen turned red: "Oh no - pwned! This email address has been found in multiple data breaches." Underneath, a list of breaches naming passwords, phone numbers, dates of birth. If that address has been yours for a decade, of course this feels bad. The fix is boring on purpose.

I run AliasFleet, an email-alias service: one forwarding address per site, so a leak names its source. The red screen is the moment that idea stops being abstract. The address in the file is the problem.

Read the compromised-data line first

Skip the banner. The useful line in each breach entry is the list of compromised data: the classes of data in the file. Email addresses, passwords, names, phone numbers, dates of birth, IP addresses, and so on. Alongside it sit the breach name, the service the data came from, and a date. Read the data list before anything else. Email addresses only means a phishing problem. Passwords means an account-takeover problem. Both means both, plus scam calls that already know your name.

Then the word itself. "Pwned" is leetspeak for "owned", a typo born from the o and p keys sitting next to each other, meaning controlled or compromised. In the same HIBP FAQ, a "breach" is an incident where data gets exposed in a vulnerable system. So the screen says your address turned up in data exposed that way, and no more.

Two banners exist. Green: "Good news - no pwnage found!" Red: the "Oh no - pwned!" line quoted above. Green feels like a clean bill of health. It is not.

Two things the screen withholds. It never shows your leaked record: breached addresses sit in storage holding nothing more than the address plus the list of breaches it appeared in. It never shows your password either, since no matching passwords come with breach emails when they are loaded.

One line for scale. At the time of writing, the homepage counter read 1,045 pwned websites and 17,846,363,019 pwned addresses. Troy Hunt, the Australian security researcher who runs the site, launched it on 4 December 2013 after the Adobe breach, as a free resource for checking whether an account had been compromised. SlashGear's explainer makes the trust case plainly; the Security Journal UK guide and the HIBP About page agree.

Pastes, stealer logs, and the rest of the page

Under the breach list you may see a second section: paste records. A paste is information posted to a publicly facing site built for sharing content, such as Pastebin. Hackers like these services because anonymous sharing is easy, and a breach often shows up there first. Your address in a paste does not immediately mean a breach disclosed it. Pastes are transient: HIBP usually indexes a new one within 40 seconds of it appearing, and keeps the addresses plus metadata. The paste itself is not kept. NetworkWorld's early report on the paste feature describes the same pipeline.

Stealer logs are worse. Malicious software on infected machines gathers email addresses, passwords, and the websites they were entered into at login, so a stealer-log hit may mean a device you use is or was infected.

A malware flag marks breach entries sourced from malware campaigns instead of a breached service: one example in the FAQ is data from the Emotet malware, provided by the US FBI and Dutch NHTCU in April 2021. Domain search covers organisations: a domain owner can check every address on a domain after proving control of it, per the HIBP support guide.

What a listing does not prove

Does pwned mean someone is in my account? No. It means your address is in a file. It does not prove anyone logged into anything, that your current password is in the file, or that you ever had an account on that service. And an old breach date does not mean old danger: a reused password from a 2013 file still opens accounts today.

Some entries carry flags that change what they mean. Unverified means the data looks real, but nobody could prove it beyond reasonable doubt. Fabricated means the opposite problem: the data probably did not come from the named site at all, likely aggregated from elsewhere. Both stay listed, because both still contain real addresses belonging to real people who deserve to know. Either way, treat the entry as exposure, but not the named site as proven guilty. Spam lists are personal data used for targeted spam, not necessarily sourced from a breached system. And two retired breaches, Ticketek and VTech, were deleted because the data is no longer circulating.

Then there are entries you will never see: 89 sensitive breaches, visible only to the verified owner after signing in to the dashboard and proving they can receive mail at that address. A public search hides them because the mere fact of having an account on some of those services could harm the person. InventiveHQ's write-up explains the mechanism the same way: the flag controls who can search, not whether the data is out there.

Then the green banner. A clean result rules out the known breaches, nothing more. The FAQ puts it in one line:

absence of evidence is not evidence of absence. Many breaches never result in the public release of data, and many go entirely undetected, so green means good news and nothing stronger. If you are wondering whether it is safe to type your address into the site, our HIBP safety guide answers that separately: searches are not logged.

Make the next breach boring

Every breach on that screen follows one pattern: a database you trusted held your real address, and then that database got out. You cannot stop databases getting out. You can stop giving them your real address.

The mechanism is one alias per site. You hand a shopping site an alias that forwards to your real inbox. The site never sees your real address. When that site is breached, the address in the dump belongs to that site alone. Our leak-tracing guide walks through the logic: the alias names its source, because only one place ever had it. You pause the alias and the phishing aimed at it dies, while your bank and your family keep using an address nobody breached.

This does not fix the breach in front of you: your real address is already in that file. What it fixes is the next one, which takes an alias instead. That is the whole pitch for AliasFleet.

Do not change your email address over one red screen. Our guide on whether to change your email after a breach reaches the same conclusion Hunt himself gives: with strong, unique passwords, he would not do anything, since a new address does not un-leak the old one.

The 10-minute fix

Work the list top to bottom. If it is long, do the email account first, then the rest.

  1. Start with passwords. Change the one on every breached service, email first, since your email is the master key: password resets for everything else flow through it. If you reused the breached password anywhere, change it there too. Attackers automate exactly this, taking leaked credentials from one site and trying them on others. HIBP's own Pwned Passwords page calls this credential stuffing.
  2. Check every password you still use against Pwned Passwords, and stop using any that has previously appeared in a breach. The check is private by construction: your password is hashed locally, only the first 5 characters of the SHA-1 hash are sent, and the full comparison happens on your side. Enzoic's summary of NIST SP 800-63B-4 adds the other half: change a password when there is evidence of compromise, not on a calendar.
  3. Turn on two-factor authentication on your email first, then banking and social accounts. A passkey or authenticator-app code beats an SMS code: Encryption Consulting's MFA guide summarises CISA's ranking, with FIDO2/WebAuthn and PKI-based authentication the only phishing-resistant methods, and SMS one-time passwords the weakest common form.
  4. Turn on breach notifications: enter your address, click the verification link in the inbox, and you get immediate notifications when your address appears in a new breach. Next time, the breach finds you.
  5. Expect phishing that quotes the real breach: the attacker has the same details you just read, the service name, the date, the fields. Freedom Press's breach guide puts it plainly: treat breach-related messages as hostile until verified another way. Do not click links in breach emails; go to the site yourself, by typing the address.
  6. If you see a stealer-log hit, or the compromised data includes passwords you typed into a password-saving browser, check the device. The same Freedom Press guide notes one of your devices may have been infected with information-stealing malware, so run the antivirus you already have and update the device.
  7. Write down the list. ProstDev's HIBP walkthrough suggests a screenshot or a note of the breaches you are in, which you will use twice: once to fix passwords, once later when phishing arrives wearing those breach names.
  8. Repeat for every address you use. SwitchingToMac's breach guide says the same: old accounts are often in the oldest and messiest leaks.

Set your expectations with one stat. TechCity's recent count of HIBP's 2026 additions found phone numbers in about 63 percent of them and passwords in only about 19 percent. That matches what the red screen usually means in practice: a scammer with your name, number and email, rather than your password.

It stays red, and that is fine

Do not expect the screen to change. Breach listings do not expire, and the file does not get un-stolen because you changed your password. The listing is a record of what happened. Your job is to make the record stale: passwords changed, reuse killed, 2FA on, notifications on, aliases in place for the next signup.

Top comments (0)