Most of the time, this isn't a security incident
Before anything else: a rejected login is far more often mundane than malicious. Three ordinary causes account for the large majority of "I can't get into my own site" reports.
- A genuinely forgotten password. WordPress's built-in "Lost your password?" link on the login screen emails a reset link to the address on file. If that email never arrives, check spam first, then confirm your host's outbound mail is actually working — a site that can't send mail at all is a separate, common configuration problem, not evidence of anything sinister.
- Your own security plugin locking you out. Login-attempt-limiting features (the same kind covered in our login-hardening guide) exist specifically to lock out repeated failed attempts — including yours, if you mistyped a password a few times or a saved browser autofill is quietly submitting a stale one. This is one of the most common sources of "my own site locked me out" confusion, and it usually resolves itself once the lockout window (typically 15–60 minutes, depending on the plugin) passes.
- A caching or CDN issue. Occasionally the login page itself fails to load correctly — a stale cached version, a CDN misconfiguration, or an overly aggressive optimization plugin interfering with the login form. This looks like an access problem but is really a page-delivery problem, and clearing your host's or CDN's cache is usually the fix.
If one of these explains what happened, there's nothing more to do here — reset the password, wait out the lockout, or clear the cache, and move on.
When it's actually a security issue
The picture changes if the password reset email never generates one because the address on file isn't yours anymore, or if you're certain your password was correct and it's simply being rejected. Two real, more serious causes:
- An attacker changed your credentials after compromising the account. Once someone gains admin access — through a leaked password, a vulnerable plugin, or a session left open on a compromised device — one of the first things they often do is change the account's password and, sometimes, its email address, specifically to lock the real owner out and buy themselves time.
- The admin account was deleted or demoted entirely. Rather than changing your credentials, an attacker with sufficient access might simply remove your administrator account, or quietly drop its role to something with far less capability. This is the acute version of the same account-integrity risk covered in our dormant admin account guide and our privilege drift guide — there, the concern is a role change that shouldn't have happened yet went unnoticed; here, it's the same kind of change discovered the hard way, at the login screen.
Regaining access when wp-admin itself is unreachable
If the normal password-reset flow is unavailable — no working email, or you no longer trust the account details on file — recovery has to happen outside of wp-admin, through either server access or the database directly. These are standard, widely-documented recovery paths, not obscure hacks:
-
WP-CLI, if you have SSH access. This is the safest option, because it goes through WordPress's own password-hashing logic rather than touching the database by hand. First list existing users to confirm the account:
Terminal
wp user list
Then reset the password for that user directly:wp user update <user-login> --user_pass="a-new-strong-password"
-
Direct database update, if SSH isn't available but phpMyAdmin (or your host's database tool) is. Open the
wp_userstable, find the account by itsuser_login, and edit theuser_passfield — most database tools offer an "MD5" function option for this specific field, which is the standard way to set it here. WordPress recognizes a plain MD5 hash as a legacy format and automatically re-hashes it into its normal format the next time that account logs in successfully, so you don't need to match WordPress's own hashing scheme by hand. -
Check
user_emailin the same row. While you're there, confirm the email address on the account is actually yours. If an attacker changed it, update it back — otherwise a future legitimate password reset will go to an address you don't control.
If your own administrator account was deleted rather than locked, and no other legitimate admin account remains, a new administrator user can be created the same way — either with wp user create in WP-CLI, or by inserting a new row into wp_users and wp_usermeta with the administrator capability set, which is a more involved manual process most hosts' support teams can walk you through directly if you're not comfortable doing it yourself.
Once you're back in, don't stop there
Regaining access is the first step, not the last one. If everything here turned out to be an innocent lockout, there's nothing further to do. But if you found evidence of an actual account takeover — a changed email, an unfamiliar admin account, a password that clearly wasn't the one you set — treat it as a full compromise, not a one-off inconvenience. Rotate every password and API key associated with the site, and work through our malware removal guide to check for anything the attacker may have left behind beyond the account change itself, since a locked-out login is frequently just the most visible symptom of a deeper intrusion.
Let SecurynAI flag unexpected admin changes and privilege drift before a lockout is the first sign you notice.
Install free →