Security

Harden a site after finding an admin password exposed in a public breach dump

A pre-incident scenario for closing the door after a credential monitoring alert, before any actual compromise, with the highest-risk part being a stale account nobody's watching.

Works with Claude / GPT310 uses 4.3

The prompt

security-admin-password-in-breach-dump
A breach-monitoring service just alerted that an email address matching one of your
WordPress admin accounts appeared in a newly published data breach dump from an
unrelated third-party service, not your WordPress site itself. There's no evidence yet
that your site has actually been accessed, but the password in that dump is the same
as, or close to, the one used on this WordPress account.

ACCOUNT: [admin@clientsite.com, an editor-level account belonging to a contractor who
left 8 months ago and was never removed]
SITE CONTEXT: [WordPress core and all plugins are up to date, no obvious signs of
compromise in the file system or recent posts]

Treat this as a "before it becomes an incident" hardening task, not a cleanup, since
the goal is closing the door before anyone walks through it:
1. State why an old, unremoved contractor account matters here specifically. Credential
   reuse plus a stale account nobody's actively watching is a materially higher risk
   than the same leaked password on an account someone logs into daily and would
   notice odd activity on.
2. Give the exact immediate steps in order: force-reset the exposed account's password,
   and separately decide whether to remove the account outright given it belongs to a
   former contractor, rather than just rotating its password and leaving it active.
3. Recommend which other accounts should have passwords rotated as a precaution even
   though only one email appeared in the dump, and explain how far that precaution
   should reasonably extend.
4. Since there's no confirmed compromise yet, specify what to actually check to rule
   one out (recent admin user creation, unexpected plugin or theme file changes, new
   scheduled tasks), rather than assuming the site is clean because nothing looks
   obviously wrong.
5. Recommend one structural fix that would have made this whole scenario lower-risk in
   the first place, such as enforcing unique passwords per site or revoking access the
   moment a contractor's engagement ends, rather than relying on a breach alert
   surfacing it months later.

Replace the account and site context details with your own situation.

The account that matters most here isn’t the one logged into every day, it’s the one nobody’s watching anymore. Offboarding gaps like this are a more common real-world entry point than any zero-day, and they’re also the easiest to fix once you know to look.