WordPress Credential Exposure: How to Check Your Site and Lock It Down

Somewhere on the internet right now, a WordPress admin login is being tried against a few thousand combinations per minute. Most of those attempts are automated, most are wasted, and a small percentage land on a site where the owner reused a password from a breach that happened years ago. If you run a WordPress site, the uncomfortable truth is that your credentials may already be circulating in a leaked database, and you would have no idea unless you went looking.

That is the problem this article addresses. If you are searching for "WordPress site compromised credentials," you are probably in one of three situations: you noticed something odd (a new admin user you did not create, a redirect to a casino site, emails from your host about suspicious logins), you read about a breach involving a plugin or a password manager and want to know if you are affected, or you are simply doing the responsible thing before anything goes wrong. All three are reasonable reasons to be here.

In this guide you will learn how credential exposure actually happens on WordPress, how to check whether your login details have leaked, how to look for signs that someone is already inside your site, and how to lock everything down in a sensible order. The steps are written so you can follow them without a developer on call. Where a tool or service can save you time, I will say so, along with the tradeoffs.

Key Takeaways

• Credential exposure usually comes from password reuse, not from WordPress core being broken. Treat every password on your site as potentially leaked until you verify otherwise.
• Check breach databases and your WordPress user list first, then review active sessions, recent logins, and file changes.
• Rotate passwords in a specific order: hosting and FTP/SFTP first, then the WordPress admin accounts, then database credentials, then API keys stored in wp-config.php.
• Enforce two-factor authentication, limit login attempts, and block abusive IP ranges. A single admin account with no second factor is the most common entry point.
• Remove users you do not recognize, reset every session, and scan for backdoors before assuming the problem is solved. Changing a password does not remove a planted PHP file.
• Build a routine: unique passwords in a manager, quarterly audits, and monitoring of login activity.

How WordPress Credentials Actually Get Exposed

Before you check anything, it helps to understand the ways credentials leak, because each one leaves different traces. Most WordPress compromises do not involve a sophisticated exploit against WordPress itself. The core project has a strong security record, and the majority of serious incidents trace back to something adjacent.

The most common causes

• Password reuse. You used the same password for your WordPress admin, your email, and a forum that was breached in 2019. Attackers take breach dumps, run them through login forms, and wait for matches. This is credential stuffing, and it accounts for a large share of automated login attempts.
• Weak admin passwords. Short or dictionary-based passwords fall to brute force, especially on sites with no rate limiting.
• Compromised plugins or themes. A vulnerable plugin can let an attacker read the database, including the password hashes in the wp_users table, or create a new administrator directly.
• Infected devices. A keylogger or infostealer on the computer you use to log in can capture credentials silently. This is why a clean machine matters as much as a strong password.
• Leaked configuration files. A misconfigured server or a backup stored in a public folder can expose wp-config.php, which contains database credentials and authentication salts.
• Hosting or FTP credentials. Often overlooked, these give full file access and are sometimes the weakest link, especially on older shared hosting accounts.

Each of these matters for the checklist that follows. If your admin password was reused, the fix is a password change. If a plugin was the entry point, changing passwords alone will not help because the attacker may still have a way back in.

Step 1: Check Whether Your Credentials Have Already Leaked

Start outside your site. The question you are answering is whether the email addresses and passwords you use are in circulation.

Use a breach-check service such as Have I Been Pwned, which lets you enter an email address and see which known breaches include it. Many password managers also run a built-in breach check against the passwords stored in your vault. If you do not yet have a password manager, the password manager setup guide walks through getting one running in about fifteen minutes, and it is the single best investment you can make before touching anything else on your site.

A worked example

Say you run three WordPress sites, a client portal, and a newsletter tool, and you have 47 accounts across 12 services. Your admin logins for the three sites all use the same password, a variation you have used since 2016. You check the breach database and find that the email tied to your account appears in two breaches, one of which exposed plaintext passwords. That single finding means every site sharing that password is at risk, not just the one you were worried about. Multiply that across your 47 accounts and the cleanup gets large fast, which is why sorting by priority matters.

Your priority order should be: hosting control panel and SFTP/FTP first (full file access), then WordPress admin accounts, then your email account that controls password resets, then everything else.

Step 2: Audit Your WordPress Users and Recent Activity

Once you know what might have leaked, look inside the site. Compromised WordPress installs often reveal themselves through users nobody remembers creating.

Walkthrough: review your user list

1. Log in to yoursite.com/wp-admin with the account you trust most.
2. Go to Users → All Users.
3. Sort by Role. Look specifically at every account marked Administrator.
4. For each unfamiliar account, note the username, email, and Registered date.
5. Check the email address on any suspicious account. Attackers often use disposable or random domains.
6. Do not delete anything yet. Export the list first (most user management plugins offer CSV export, or you can copy the table) so you have a record.

If you find a user created in the last few weeks that you did not make, treat the site as compromised until proven otherwise.

Check login and session history

WordPress does not log logins by default, so you need a plugin or your host's logs. Security plugins such as Wordfence, Solid Security, or the activity log features in several premium suites record every login attempt, the IP address, and the timestamp. Look for successful logins from countries or times that do not match your own activity. A login at 3:12 a.m. from a server hosting provider you have never used is a strong signal.

Your host's control panel may also show SSH, SFTP, and file manager access logs. These are often more reliable than plugin logs because the plugin itself may be what was compromised.

Step 3: Look for Backdoors and Modified Files

This is the step most people skip, and it is the one that causes repeat compromises. An attacker who gets admin access often plants a secondary way back in: a PHP file hidden in an uploads folder, a modified theme file, or a rogue plugin with a disguised name. If you only change the password, the backdoor keeps working.

A practical file audit

1. Compare your WordPress core files against a clean copy. You can run wp core verify-checksums from WP-CLI if your host provides shell access. This reports any core file that has been altered.
2. Look for PHP files inside wp-content/uploads. Uploads should contain images, documents, and media. A .php file there is almost always malicious.
3. Check for recently modified files. Sort by modification date across your wp-content folder and look for anything changed in the window when you suspect the intrusion began.
4. Review your plugin and theme list. Remove anything you do not actively use and anything you do not recognize.
5. Search your files for common obfuscation patterns such as eval(base64_decode(. Legitimate code rarely needs this.

A malware scanner helps here. Wordfence, Sucuri, and Solid Security all offer file scanning, and SiteGuard Pro is one option if you want a dedicated protection layer that watches for file changes continuously rather than only when you run a scan.

Step 4: Rotate Credentials in the Right Order

Once you have checked for leaks and audited the site, it is time to change passwords. The order matters. If you change the WordPress admin password first but the attacker still holds your FTP credentials, they can simply upload a new backdoor.

Rotation sequence

1. Hosting control panel. Change this password and enable two-factor authentication if the host supports it.
2. FTP/SFTP accounts. Delete unused accounts and rotate the rest. Prefer SFTP and key-based login where available.
3. Your email account. Anyone who controls the email tied to your WordPress admin can reset your password. Secure this before the site.
4. WordPress admin accounts. Change every administrator password. Use the password manager to generate new ones of at least 20 characters.
5. Database credentials. Update the database password in your host panel and then in wp-config.php. Note that changing this will briefly break the site until the config is updated, so do it during a quiet window.
6. Authentication keys and salts. In wp-config.php, regenerate the security keys using the official WordPress salt generator. This invalidates every existing login cookie.
7. Third-party API keys. Rotate keys for payment gateways, mail services, and anything stored in plugin settings.

Step 4 has a side effect that is worth knowing about: regenerating salts logs everyone out, including you. Plan for this.

Step 5: Lock the Site Down So It Stays Locked

Rotating passwords fixes today's problem. Hardening prevents the next one. The aim is to make your admin login expensive to attack and easy for you to monitor.

The baseline controls

• Two-factor authentication on every admin account. This single control blocks most credential stuffing, because a stolen password is no longer enough.
• Login rate limiting. Lock or delay an IP after a set number of failed attempts. Most security plugins do this.
• Change the default login path or add a firewall rule. Moving wp-login.php behind a rule reduces automated noise. It is not a substitute for 2FA but it cuts the volume of attempts you have to watch.
• Disable file editing in the dashboard. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php so that even an admin cannot edit theme or plugin code from the browser.
• Remove inactive users and reduce roles. Most users need Author or Editor, not Administrator.
• Keep ever

  Cover image: Innovate Maryland Emerging Technology Center by MDGovpics, licensed under BY 2.0 via Openverse.