When credentials get breached, the fastest way to stop an attacker isn’t just changing passwords. It’s resetting the whole access path: users, cookies, and sessions. In 2026, WordPress sites get hit in ways that still leave “old” logins alive even after you change a password. That’s why I treat this like a checklist, not a vibe.
A breached credentials response plan is a step-by-step recovery method to remove stolen access and force fresh logins. In plain terms, you cut every “door” the attacker may already be using—then you rebuild it in a safer way.
Below is the same kind of plan I use when I’m cleaning up real compromised WordPress sites (the ones where the admin dashboard looks normal, but the attacker is still inside).
What “breached credentials” really means for WordPress logins
The key idea: a breached password isn’t only a future problem—it’s an active access problem. Attackers often log in right away, then keep using the session until it ends. If you only reset passwords, the attacker may stay logged in through an existing session cookie.
In WordPress, sessions are commonly tracked using cookies in the browser (like wordpress_logged_in_*) and sometimes via server-side session storage, depending on your setup (security plugins, caching layers, and custom auth can change things).
Here’s what I look for when I suspect breached credentials:
- New admin users you didn’t create
- Logins from odd countries or long gaps in normal activity
- Remember-me behavior (“stay logged in” even after password resets)
- Permission changes on roles (Author turned into Administrator, for example)
- Admin actions that keep happening after you “lock things down”
If you want deeper context on the start of the cleanup process, you may also like our post on WordPress malware cleanup checklist. That guide covers scanning and file checks, but this one focuses on the access reset part.
Breached Credentials Response Plan (step-by-step) for resetting users
Your #1 job is to remove every way the attacker can log in as you. That means locking down users first, then forcing a clean login for everyone.
Step 1: Identify what got exposed (and what you don’t know yet)
Don’t guess. Check where the breach likely came from. Was it a reused password from another site? A data leak from a hosting provider? A plugin vulnerability that revealed usernames?
In my work, this is usually what happens:
- The email server shows a login alert or password reset request you didn’t cause.
- WordPress shows a successful login for an admin account at an odd time.
- A security plugin shows repeated failed attempts, then one successful admin login.
If you can’t identify the source, you still proceed with the same recovery steps. The goal is to stop access, not to win an investigation in a day.
Step 2: Freeze access while you act (so the attacker can’t keep changing things)
Before you reset everything, slow the attacker down. Turn on maintenance mode (or temporarily block access) so you can update safely without race conditions.
In 2026, I recommend doing this even for small business sites. Even a few minutes matters if an attacker is actively scheduling uploads, creating users, or changing settings.
Practical move:
- Enable maintenance mode in your hosting panel or with a WordPress maintenance plugin.
- Pause cron jobs if your host allows it (or disable non-essential scheduled tasks).
- Keep the admin IP(s) able to access the site if you can.
Step 3: Audit WordPress users for changes
Go to Users > All Users and check for anything new or suspicious. A real case I handled in 2026: the attacker didn’t change passwords right away. Instead, they created a new admin user with a normal-sounding name and waited for staff to reset credentials later.
Check:
- Users created in the last 24–72 hours (or since the breach date)
- Any role changes: Subscriber/Author/Admin
- Users tied to “unused” email accounts
- Accounts with recent “last login” times that don’t match your staff schedule
What most people get wrong: They delete the new user and move on. But if the attacker is still logged in via a session cookie, they can recreate that account again. So deletions only make sense after you force session logout (more on that below).
Step 4: Reset admin credentials with a tight timeline
Reset passwords for every account that can access wp-admin. If you’re not sure who should be included, reset these roles at minimum:
- Administrators
- Editors (if they can install plugins or modify site settings)
- Any user with access to staging, deployment tools, or FTP/SFTP (even if not a WordPress admin)
Timeline I use:
- Minute 0–10: Identify suspicious users and lock down changes.
- Minute 10–30: Reset passwords for all admin users.
- Minute 30–45: Force logout and reset sessions/cookies (this is the part many miss).
- Same day: Confirm login logs stop showing odd activity.
Use unique passwords generated by a password manager. I’ll say it plainly: sending passwords over email or chat is risky. A leaked inbox can turn your “reset” into a loop.
Force logout: reset sessions so stolen cookies stop working
Resetting cookies and sessions is the part that saves you when an attacker is already logged in. If you only change passwords, the old session cookie can still let them keep control until it expires.
Session data is basically “who you are” stored for the user, so it doesn’t need to check the password every time. A breached credentials response plan must invalidate those saved logins right away.
Step 5: Log out everyone from WordPress (practical methods)
WordPress doesn’t give you a perfect “log out all sessions” button in core, but you have options.
Method A (best for many sites): Use a security plugin feature that invalidates sessions. Some plugins include “Force logout” or “Invalidate sessions” after password changes.
Method B (works when plugins don’t help): Use a session/cookie invalidation approach via WordPress hooks or by changing auth keys.
Method C (strong and simple): Change WordPress authentication salts. This forces WordPress to treat existing cookies as invalid.
Which method should you use? If you have a security plugin installed with a known “force logout” function, use it. If not, change auth salts. It’s reliable.
Step 6: Change WordPress authentication salts to invalidate cookies
WordPress stores a few special values called authentication salts. They’re part of how WordPress signs login cookies.
When you change these salts, existing cookies won’t match the new signatures anymore, so users (and attackers) get logged out.
Where to do it:
- Open your
wp-config.php - Find the lines like
AUTH_KEY,SECURE_AUTH_KEY,LOGGED_IN_KEY, and their “SALT” pairs - Replace each value with a new random string
How to generate new values safely:
- Use the official WordPress salt generator (the one provided by WordPress.org).
- Copy each new value directly into
wp-config.php.
Experience note: I’ve seen sites that change only one key and wonder why “it didn’t kick out” the attacker. Change all AUTH/SALT pairs together so the cookie signatures fully break.
What you should expect: everyone gets logged out. That’s normal. Plan a short maintenance window so staff isn’t surprised.
Step 7: Clear browser cookies for staff (yes, for real)
Even after auth salts change, staff browsers may keep old cookies cached until they reload. Make it simple: after you force logout, ask your team to clear cookies for your domain or sign out and sign in fresh.
If you’re the only admin, you still need to test it from a private window (incognito). Private browsing helps confirm you’re not still using old cookies.
This is a small step, but I’ve watched it catch issues in real incidents: staff thinks “password reset worked,” but they were still logged in from an old session on a different device.
Reset cookies and sessions safely when you use WordPress security plugins
Security plugins can help, but they can also hide what’s really happening. Different tools manage sessions in different ways, so you should understand what they do before you start deleting things.
Here’s how I approach plugin-based setups in 2026:
Know the difference: cookie invalidation vs. session storage reset
Cookie invalidation means the browser no longer has a cookie that matches WordPress’ signed login rules. Session storage reset means any stored server-side session data is cleared or marked invalid.
If your plugin only invalidates cookies, but your site uses server-side sessions (for example, via custom auth or a session plugin), the attacker may still have an active session through a different mechanism.
That’s why I like the auth salt change method. It’s cookie-signature based, so it punches through many plugin layers.
What to do if you use a caching or CDN layer (Cloudflare, LiteSpeed, etc.)
CDNs don’t usually store your login cookies, but caching layers can mess with what you see during troubleshooting. For example, after you change salts, you might still see old admin pages due to cached assets or stale redirects.
My safe approach:
- Clear server cache and CDN cache after auth changes.
- Test login and logout in an incognito window.
- Verify that
/wp-login.phpforces a fresh login for staff.
If you’re using a WAF or bot protection, keep an eye on login challenges. Sometimes security tools require extra steps during recovery, and it can look like “sessions didn’t reset” when it’s just a challenge loop.
People Also Ask: breached credentials response plan questions
These are the questions I get most often from small business owners after a suspected credential breach.
How do I force logout after a password reset?
In WordPress, the most reliable way to force logout is to change the authentication salts in wp-config.php. This invalidates the login cookie signatures, so existing sessions stop working. If you have a security plugin with a “force logout” feature, use that too—but salts are the strong fallback.
Do I need to reset cookies after changing passwords?
Yes, you should assume you do, because breached credentials can already be tied to active sessions. Changing passwords stops new logins, but session cookies can keep an attacker logged in. The safer move is to invalidate sessions immediately using salts and confirm with an incognito test.
Will changing WordPress authentication salts log out all users?
Yes. Changing AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, and the related salt pairs logs out everyone who has an active login cookie. Plan a maintenance window and reset staff access right after.
What’s the difference between resetting sessions and resetting users?
Resetting users means updating or removing accounts and permissions (passwords, roles, removing unknown admins). Resetting sessions means ending the active login tokens so attackers can’t keep using an existing session. You need both for a breached credentials response plan to be complete.
Reset access without breaking your site: a safe order of operations
If you do this in the wrong order, you can accidentally lock yourself out while the attacker still has a valid session. The order matters.
Here’s a safe order I’ve used on live sites with real downtime limits:
- Freeze changes: enable maintenance mode and pause risky tasks.
- Audit users: remove unknown admins and review roles.
- Reset admin passwords: update all admin credentials immediately.
- Invalidate sessions: change WordPress auth salts or use a force-logout feature.
- Clear caches: server + CDN caches to avoid misleading “old page” views.
- Test logins: use incognito windows to confirm sessions are gone.
- Re-enable access: turn off maintenance mode and monitor logs.
Notice the middle: invalidating sessions comes right after password resets. That’s intentional. It closes the “password changed but cookie still works” gap.
Monitoring after the reset: what “good” looks like in the next 24 hours
Once you reset users, cookies, and sessions, your job isn’t done. You watch for signs the attacker is still inside or still probing.
For the next 24 hours, check these:
- Login attempts: watch for repeated failed logins and any successful logins by the wrong account.
- User changes: check if new admin users appear.
- Plugin and theme changes: watch for new admin-installed plugins or edited theme files.
- New admin email notifications: set alerts for user creation and admin actions.
If you use a logging plugin or security suite, focus on “successful admin logins” rather than just failed attempts. Attackers often stop after the reset, but they may test again.
Also check your hosting control panel logs. Many small business owners only review WordPress logs and miss brute-force activity at the server level.
Common mistakes that turn a reset into a loop
I’ve seen the same mistakes repeat across many cleanups. Avoid these and you’ll save hours.
Mistake 1: Deleting the attacker’s user before forcing logout
If the attacker has a valid session, they can keep making changes. Deleting their account early may only buy you a few minutes.
Mistake 2: Resetting passwords but forgetting other admin paths
WordPress isn’t the only login. If an attacker has FTP/SFTP access, they can re-edit files. If they have access to your hosting panel, they can do changes there too.
Reset passwords for:
- Hosting control panel admin
- FTP/SFTP users
- Email accounts used for password resets
- Any CI/CD or staging tool accounts
Mistake 3: Not changing salts when you suspect active session use
Plugins vary. Some force logout in one context but not another. When you suspect breached credentials are actively in use, auth salt changes are your reliable move.
Mistake 4: Skipping cache clear, then troubleshooting the wrong thing
You change salts and expect to be logged out instantly. If you’re seeing stale pages, you might think your change didn’t work. Always clear caches and test in incognito.
Hardening after the incident: stop the next breached credentials before it happens
Resetting access is step one. Step two is reducing the chance of another incident. In 2026, the best WordPress hardening is boring and consistent.
Turn on multi-factor authentication (MFA) for admins
MFA is still one of the highest impact fixes for breached credentials. Even if a password leaks, the second step stops most real attacks.
If you can, use an app-based authenticator or hardware key for your main admin. SMS is better than nothing, but it’s not my first choice.
Lock down file edits and limit who can install plugins
Attackers often repeat the “create admin user + install a backdoor plugin” pattern. If only one person can install plugins, you shrink the risk area.
In WordPress security hardening, principle of least privilege matters. It just means: give each user the smallest access they need to do their job.
We cover this in more detail in our WordPress hardening tips for small businesses post.
Set up real alerts for login and admin actions
Don’t wait for an attacker to leave evidence. Use alerts for:
- User creation
- Admin role changes
- New plugin/theme installs
- Successful logins to admin accounts
In a case study we ran last year, the owner got an alert within 2 minutes of a new admin login and stopped the attacker before they installed anything. That quick notice mattered more than any single cleanup step.
How much does a breached credentials response typically cost vs. doing it yourself?
There’s no one price, but I can give you a realistic range I see for WordPress security and malware cleanup service work in 2026.
DIY usually costs time. If you need to edit wp-config.php, reset salts, review user tables, and check logs, it can take 2–6 hours for someone who’s done it before. For most owners, it takes longer because you also need to confirm everything works after changes.
Professional help usually costs more, but it’s faster and reduces risk. Many engagements fall around:
- Small cleanup (access reset + scan): a few hundred dollars
- Full incident response (malware + access + monitoring): more depending on scope
The real cost difference is hidden: mistakes can keep the site down or re-open the attacker’s path. My recommendation is simple—if you suspect active access, don’t “experiment” on your production site. Use a staging site or get help.
When you should not use this plan (and what to do instead)
This plan is solid for most WordPress incidents where breached credentials are the key problem. But there are situations where you should slow down:
- Your site uses a custom auth system that depends on session behavior you don’t fully understand.
- You can’t change
wp-config.phpbecause you don’t have access to the server or hosting controls. - You’re under a strict compliance timeline and need documented audit steps.
If any of those apply, you’ll want a guided incident response. The goal is to invalidate access without breaking your auth flow.
Conclusion: the quickest safe fix is “reset passwords, then invalidate sessions”
If you only remember one thing, make it this: a breached credentials response plan isn’t complete until sessions stop working. Resetting users (passwords and accounts) closes the “new logins” path. Resetting cookies and sessions (especially via WordPress authentication salts) kills the “already logged in” path.
Do it in the right order: freeze changes, audit users, reset passwords, invalidate sessions, clear caches, then monitor for 24 hours. That sequence is what keeps your recovery from turning into a repeat incident.
Next step: If you’re already cleaning a compromised site, pair this plan with our WordPress malware cleanup checklist so you don’t stop at access. Attackers don’t always stop after you lock them out—they often leave behind code, redirects, or new admin tools.
Featured image alt text suggestion: “Breached Credentials Response Plan reset WordPress users cookies sessions after suspicious login”