Support Library

Published Data Breaches of Your Site: What to Do

When a website’s user database is stolen and leaked, Have I Been Pwned (HIBP) records the breach so people can find out whether their details were in it. A listing for your own site means its accounts are in circulation, and attackers will try those email and password pairs on your site and everywhere else for years.

Author
CategoryWebsite Security
Length4 minute read
UpdatedNovember 1, 2026

The short answer

Make sure every affected account has had its password reset, turn on multi-factor authentication (MFA) for sign-ins, block known-breached passwords, and watch for credential stuffing: many failed sign-ins from many addresses. If the breach is recent, follow your incident and notification obligations.

How a breach keeps causing harm

How leaked credentials are reused after a breach, and how resets and MFA stop it Top, not handled: the site’s user database leaks, the email and password pairs are shared, and attackers replay them against the site and other services, taking over accounts where passwords were not changed. Bottom, handled: affected passwords are reset, MFA is required and breached passwords are rejected, so the replayed credentials fail. Breach not handled Database leaked Emails and hashes Passwords cracked Weak hashes fall fast Credential stuffing Replayed everywhere Accounts taken Here and elsewhere Old passwords still work Users hit on other sites too Breach handled Passwords reset All affected accounts MFA required Password is not enough Breached passwords Rejected at sign-up Stuffing fails Rate limits, alerts Leaked pairs no longer work Attacks are noticed How leaked credentials are reused after a breach, and how resets and MFA stop it Top, not handled: the site’s user database leaks, the email and password pairs are shared, and attackers replay them against the site and other services, taking over accounts where passwords were not changed. Bottom, handled: affected passwords are reset, MFA is required and breached passwords are rejected, so the replayed credentials fail. Breach not handled Database leaked Emails and hashes Passwords cracked Weak hashes fall fast Credential stuffing Replayed everywhere Accounts taken Here and elsewhere Old passwords still work Users hit on other sites too Breach handled Passwords reset All affected accounts MFA required Password is not enough Breached passwords Rejected at sign-up Stuffing fails Rate limits, alerts Leaked pairs no longer work Attacks are noticed
Leaked password lists are combined and resold for years, so even a breach from long ago keeps being replayed.

How DNS Panopticon detects it

Security Posture asks HIBP for breaches of the scanned site (for example adobe.com’s 2013 breach). Only breaches HIBP has verified are counted, and only breach names, dates and counts are shown, never any personal data. The result appears on the Credential Exposure card.

FindingSeverityWhen it appears
The site’s accounts were in a published breachHigh, medium or lowHigh for a breach in the last two years, medium if passwords were taken or it is up to five years old, low for older ones. Several breaches add up.
No published breaches of the sitePassHIBP has no verified breach of the domain. Unverified ones are mentioned but not counted.
Breach list could not be checkedNot gradedHIBP did not answer.

This is about breaches of your site. Staff whose own passwords leaked elsewhere, or whose computers were infected, are covered in Infostealer Malware and Stolen Logins.

How to check it yourself

Page or commandWhat it tells you
https://haveibeenpwned.com/PwnedWebsitesEvery breach HIBP has loaded, searchable by site name, with what data was taken.
curl -s "https://haveibeenpwned.com/api/v3/breaches?domain=example.com"The breaches HIBP links to a domain, as JSON. No API key is needed for this call.
https://haveibeenpwned.com/DomainSearchFor a domain you can prove you own: which of your organisation’s addresses appear in any breach.

Why it matters

  • Password reuse. Many people reuse passwords, so a leak from your site opens their accounts elsewhere, and leaks elsewhere open accounts on your site.
  • Credential stuffing is constant. Attackers run leaked lists against sign-in pages automatically and at scale.
  • Trust and obligations. Customers, insurers and regulators look at how breaches were handled. Under GDPR, for example, a personal data breach must normally be reported to the regulator within 72 hours of becoming aware of it.

How to respond

  1. If the breach is recent, run your incident response: contain the cause, preserve evidence, and work out who must be notified (regulators, affected users, partners).
  2. Reset affected passwords, or require a reset at next sign-in, and end existing sessions.
  3. Store passwords properly with a slow, salted hash such as Argon2id, scrypt or bcrypt, not MD5 or SHA-1.
  4. Turn on MFA, ideally passkeys or another phishing-resistant method, at least for admin and high-value accounts.
  5. Reject breached passwords at sign-up and password change, for example with the HIBP Pwned Passwords range API, as NIST SP 800-63B recommends.
  6. Defend the sign-in page with rate limiting, bot detection and alerts on bursts of failed sign-ins.
  7. Tell users plainly what was taken and what to do, including changing the same password anywhere else they used it.

FAQ

The breach was ten years ago. Does it still matter?

Less, which is why older breaches cost fewer points. But leaked lists stay in circulation, and some users never changed their passwords. Make sure resets were enforced and MFA is available.

Why can’t DNS Panopticon show which of our staff were in breaches?

HIBP only answers per-address domain searches for the verified owner of a domain. You can run that search yourself in HIBP’s domain search after proving ownership.

HIBP lists an unverified breach of our site. What should we do?

Unverified breaches may be fabricated or recycled data, so DNS Panopticon does not count them. Contact HIBP if you believe it is wrong, and check your own logs in case it is real.

Sources and further reading

Related support articles

Infostealer Malware and Stolen LoginsSecure, HttpOnly and SameSite Cookie FlagsForms and Passwords Sent over Plain HTTP