Skip to main content
Blog|
How-to guides

Locked out of WordPress admin: how to get back in

|
Mar 24, 2026|14 min read
HOW-TO GUIDESLocked out of WordPress admin:how to get back inHOSTNEYhostney.comMarch 24, 2026

Getting locked out of your WordPress admin panel is one of the more frustrating experiences in site management. You know the site is running, you can see the frontend, but the login page either rejects your credentials, blocks your IP, throws an error, or redirects you somewhere unexpected. Unlike a site that is completely down, a lockout means everything works except your ability to manage it.

The causes range from simple (you forgot the password) to serious (an attacker changed your credentials). Most lockouts can be resolved in a few minutes with SSH or SFTP access, but the approach depends entirely on why you are locked out. Here are the seven most common causes and how to fix each one.

Why you get locked out#

WordPress admin access depends on several things working together: correct credentials stored in the database, a functioning login page served by PHP, no IP-level blocks between you and the server, and intact user roles in the wp_users and wp_usermeta tables. A failure in any one of these will lock you out.

Some lockouts are self-inflicted – a forgotten password, a security plugin misconfiguration, or a changed login URL you did not bookmark. Others are defensive responses from the server – rate limiting after too many failed attempts, or a firewall rule triggered by suspicious behavior. And some are the result of a compromise, where someone else gained access and removed yours.

The fix always starts with the same question: can you still access the server via SSH or SFTP? If yes, you can fix almost any lockout. If not, you need to contact your hosting provider.

Cause 1: Forgotten password#

This is the most common lockout by far. You have not logged in for a while, the password manager does not have the entry, or someone else set up the site and never shared the credentials.

How to diagnose

You enter what you think is the correct password on wp-login.php and get “The password you entered for the username [x] is incorrect.” The login page itself loads fine, there are no errors, and you are not being redirected anywhere strange. The problem is simply that you do not know the password.

How to fix

Option 1: Password reset email

Click “Lost your password?” on the login page. WordPress will send a reset link to the email address associated with the admin account. This is the simplest fix, but it only works if:

  • The email address on the account is one you can access
  • The server can send outgoing email (many servers have this disabled or filtered)
  • The reset email is not landing in spam

If the email never arrives, move to option 2 or 3.

Option 2: WP-CLI

If you have SSH access, WP-CLI can reset the password directly:

wp user list --role=administrator

This shows all admin accounts. Then reset the password for the one you need:

wp user update admin_username --user_pass="your_new_password"

Replace admin_username with the actual username from the list.

Option 3: Direct database update

If WP-CLI is not available, connect to MySQL and update the password directly:

UPDATE wp_users
SET user_pass = MD5('your_new_password')
WHERE user_login = 'admin_username';

Note that this sets an MD5 hash, which is weaker than WordPress’s default phpass hashing. It works for login, but WordPress will automatically rehash the password with phpass the next time you log in. So log in immediately after running this query and the password will be upgraded automatically.

If you are not sure what the admin username is:

SELECT u.user_login, u.user_email
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%';

Adjust the table prefix if your site uses something other than wp_ .

Cause 2: Security plugin blocking your IP#

Security plugins like Wordfence, iThemes Security, Sucuri, and All In One WP Security maintain their own blocklists. If you (or someone on your network) triggered too many failed login attempts, the plugin may have banned your IP address. Some plugins also block IPs based on geographic location or suspicious request patterns.

How to diagnose

The symptoms vary by plugin:

  • Wordfence: You see a page saying “Your access to this site has been limited” with a reason and your IP address
  • iThemes Security: The login page does not load at all, or you get a 403 Forbidden error
  • All In One WP Security: You get redirected or see a blank page

Try loading the site from a different network (your phone’s mobile data, a VPN, or a different location). If the login page works from another IP, your current IP is blocked.

How to fix

Via SFTP – disable the plugin:

Rename the plugin’s folder to deactivate it:

# Wordfence
mv wp-content/plugins/wordfence wp-content/plugins/wordfence.disabled

# iThemes Security
mv wp-content/plugins/better-wp-security wp-content/plugins/better-wp-security.disabled

# All In One WP Security
mv wp-content/plugins/all-in-one-wp-security-and-firewall wp-content/plugins/all-in-one-wp-security-and-firewall.disabled

Log in, then rename the folder back and configure the plugin to whitelist your IP.

Via WP-CLI:

wp plugin deactivate wordfence

Via database – clear the Wordfence blocklist:

DELETE FROM wp_options WHERE option_name LIKE '%wordfence%blocked%';

This is a less precise approach and you should reactivate the plugin afterward to make sure your settings are intact.

After regaining access, add your IP (or your office IP range) to the plugin’s whitelist so this does not happen again. If you are dealing with repeated blocks from brute force attempts on your site, see Brute force attacks on WordPress: how they work and how to stop them for a deeper look at the problem.

Cause 3: Too many failed login attempts triggering server-level blocking#

This is different from a plugin-level block. The server itself – through rate limiting, fail2ban, a web application firewall, or your hosting provider’s security layer – has blocked your IP. Security plugins are not involved.

This frequently happens when bots are hammering your login page with brute force attempts from many IPs, and your IP happens to get caught in the same net. It also happens if you genuinely entered the wrong password too many times in a row.

How to diagnose

The login page does not load at all. You get a connection timeout, a 403 Forbidden from the server (not from a plugin), or a “too many requests” (429) response. The rest of the site may or may not load depending on how the block is configured.

The key difference from Cause 2: disabling security plugins via SFTP does not help, because the block is at the server level, not the application level.

How to fix

If you have SSH access to the server:

Check fail2ban:

sudo fail2ban-client status
sudo fail2ban-client status wordpress

If your IP is in the banned list:

sudo fail2ban-client set wordpress unbanip YOUR_IP_ADDRESS

Check the server firewall:

sudo iptables -L -n | grep YOUR_IP_ADDRESS

If your IP appears in a DROP or REJECT rule, remove it:

sudo iptables -D INPUT -s YOUR_IP_ADDRESS -j DROP

If you do not have SSH access:

Contact your hosting provider. They can check their firewall and rate limiting rules and unblock your IP. Most providers have a support process for this exact situation.

Prevention:

Use a password manager so you do not trigger lockouts with failed attempts. If bots are causing the server to aggressively rate-limit everyone, that is a traffic management problem. See What happens when bots find your WordPress login for what actually occurs when automated scripts target your login page.

Cause 4: Plugin conflict breaking the login page#

A plugin update or activation can break wp-login.php itself. Instead of a working login form, you see a white screen, a PHP fatal error, a 500 Internal Server Error, or a partially rendered page. The login page is not rejecting your credentials – it cannot even display the form.

This is essentially the White Screen of Death happening specifically on the login page.

How to diagnose

Visit wp-login.php and check what you see:

  • White screen: A PHP fatal error is occurring but error display is turned off
  • 500 Internal Server Error: PHP is crashing during the login page render
  • Partial page with PHP error text: The error is being displayed, which tells you exactly what is wrong

Enable error display temporarily by adding this to wp-config.php via SFTP:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);

Reload the login page. If a plugin is causing the crash, you will see something like:

Fatal error: Cannot redeclare function_name() in /wp-content/plugins/plugin-name/file.php on line 123

You can also check the PHP error log without enabling display:

tail -50 wp-content/debug.log

How to fix

Disable all plugins at once via SFTP:

mv wp-content/plugins wp-content/plugins.disabled
mkdir wp-content/plugins

This deactivates every plugin. Try logging in. If it works, the problem is one of the plugins. Rename the folder back:

rm -rf wp-content/plugins
mv wp-content/plugins.disabled wp-content/plugins

Then disable plugins one at a time via WP-CLI to find the culprit:

wp plugin deactivate --all
wp plugin activate plugin-name

Test the login page after each activation.

Via database:

UPDATE wp_options
SET option_value = 'a:0:{}'
WHERE option_name = 'active_plugins';

This tells WordPress that no plugins are active. Log in, then reactivate plugins one by one from the dashboard.

For more on diagnosing plugin-related crashes, see WordPress 500 internal server error.

Cause 5: Corrupted user role or capabilities#

WordPress stores user roles and capabilities as a serialized PHP array in the wp_usermeta table. If this data gets corrupted – through a failed plugin update, a broken migration, a database import error, or a plugin that modifies roles and crashes midway – your admin account may no longer have the administrator role.

The symptoms are subtle. You can log in, but the dashboard is nearly empty. Menus are missing. You cannot access plugins, themes, settings, or users. WordPress treats you as a subscriber or a role with no capabilities.

How to diagnose

Log in and check what menus you see. If you only see “Dashboard” and “Profile” in the sidebar, your account has lost its administrator role.

Via WP-CLI:

wp user get admin_username --field=roles

If this returns something other than “administrator” (or returns empty), the role is wrong.

Via database:

SELECT meta_value
FROM wp_usermeta
WHERE user_id = 1
AND meta_key = 'wp_capabilities';

A healthy administrator entry looks like:

a:1:{s:13:"administrator";b:1;}

If the value is empty, contains only subscriber , or is malformed serialized data (broken string lengths, missing closing braces), the capabilities are corrupted.

How to fix

Via WP-CLI:

wp user set-role admin_username administrator

Via database:

UPDATE wp_usermeta
SET meta_value = 'a:1:{s:13:"administrator";b:1;}'
WHERE user_id = 1
AND meta_key = 'wp_capabilities';

Make sure you also check the wp_user_level meta key. For administrators, this should be 10:

UPDATE wp_usermeta
SET meta_value = '10'
WHERE user_id = 1
AND meta_key = 'wp_user_level';

Replace user_id = 1 with the actual user ID of your admin account. Adjust the meta key prefix if your table prefix is not wp_ .

If capabilities keep getting corrupted, a plugin is likely modifying roles on every page load and failing. Disable plugins and check which one is responsible.

Cause 6: Changed wp-admin URL via security plugin and forgot the new URL#

Several security plugins offer the option to change the default login URL from wp-login.php to something custom, like my-secret-login . The idea is to hide the login page from bots. The problem is that if you forget the custom URL, you cannot find your own login page.

How to diagnose

Visiting wp-login.php or wp-admin returns a 404 Not Found page. The site’s frontend works fine. You know your credentials are correct but you literally cannot find the login form.

How to fix

Figure out which plugin changed the URL:

The most common plugins that do this:

  • WPS Hide Login – stores the custom URL in  wp_options  as  whl_page
  • iThemes Security – stores it in its serialized settings
  • All In One WP Security – stores it in  wp_options  as  aio_wp_security_configs

Via database:

-- WPS Hide Login
SELECT option_value FROM wp_options WHERE option_name = 'whl_page';

-- Check for other hide-login plugins
SELECT option_name, option_value FROM wp_options
WHERE option_value LIKE '%login%' AND option_name LIKE '%hide%';

The result tells you the custom URL. Visit yourdomain.com/custom-url to access the login page.

If you just want to undo it:

Deactivate the plugin via SFTP:

mv wp-content/plugins/wps-hide-login wp-content/plugins/wps-hide-login.disabled

Or via WP-CLI:

wp plugin deactivate wps-hide-login

This restores the default wp-login.php URL immediately.

Via database (nuclear option):

DELETE FROM wp_options WHERE option_name = 'whl_page';

Then deactivate the plugin through the database or SFTP to prevent it from re-applying the setting.

Changing the login URL provides minimal actual security. Bots do not just guess URLs – they look for specific WordPress signatures in the HTML source. If you want to protect your login page from automated attacks, rate limiting and strong passwords are far more effective. See Brute force attacks on WordPress: how they work and how to stop them for approaches that actually work.

Cause 7: Compromised site - attacker changed credentials#

This is the most serious cause. Someone gained access to your WordPress admin (through a stolen password, a vulnerable plugin, or a brute force attack) and changed the admin password, the admin email, or both. They may have also created new admin accounts, modified your user role, or deleted your account entirely.

How to diagnose

Signs that point to a compromise rather than a simple lockout:

  • Your password stopped working suddenly, and you did not change it
  • The password reset email goes to an address you do not recognize
  • New admin accounts exist that you did not create
  • The site content has been modified (new pages, injected links, redirects)
  • Your hosting provider sent a malware notification

Check via database:

-- List all admin accounts
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered;

Look for accounts you do not recognize, especially recently created ones.

-- Check if your email was changed
SELECT user_email FROM wp_users WHERE user_login = 'your_username';

How to fix

Step 1: Regain access immediately

Reset your password via MySQL (see Cause 1, Option 3) and restore your email:

UPDATE wp_users
SET user_pass = MD5('temporary_strong_password'),
    user_email = 'your_real_email@example.com'
WHERE user_login = 'your_username';

Step 2: Remove unauthorized admin accounts

-- First, identify the rogue accounts
SELECT u.ID, u.user_login, u.user_email
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
AND u.user_login NOT IN ('your_username', 'other_legit_admin');

Delete them via WP-CLI:

wp user delete ROGUE_USER_ID --reassign=YOUR_USER_ID

Step 3: Reset all security credentials

Update the WordPress security salts in wp-config.php . Visit https://api.wordpress.org/secret-key/1.1/salt/ to generate new ones, then replace the existing salt block in your config file. This invalidates all existing login cookies and forces every user to log in again.

Step 4: Investigate the breach

Regaining access is just the first step. You need to find out how the attacker got in, or they will get back in. Check for backdoors in your theme and plugin files, review recently modified files, and scan for malware. The full recovery process is covered in My WordPress site was hacked: what to do right now and WordPress malware: how it gets in and how to remove it.

How Hostney helps with this#

Several features in the Hostney platform reduce the risk of admin lockouts and make recovery faster when they do happen.

Admin login from the control panel. The Hostney control panel has a built-in admin login feature that bypasses wp-login.php entirely. Go to Development > WordPress, select your site, click Manage, and click the Admin login button. This creates a short-lived SSO session (60 seconds to use it) that logs you directly into the WordPress dashboard. If your lockout is caused by a forgotten password, a broken login page, a security plugin blocking your IP, or a hidden login URL, the Admin login button gets you in without needing to fix the underlying problem first. You can then fix the issue from inside WordPress.

Server-level brute force protection without locking you out. Hostney’s bot detection system handles brute force attempts at the edge before they reach WordPress. Instead of relying on WordPress security plugins that maintain their own IP blocklists (and inevitably block legitimate users), the platform uses proof-of-work challenges to separate humans from bots. Real users solve a quick challenge and continue. Bots fail and get blocked. Your IP does not end up in a blocklist just because you mistyped your password twice.

SFTP access is always available. Even if the WordPress login is completely broken – white screen, plugin conflict, corrupted roles – you can always connect via SFTP to rename plugin folders, edit wp-config.php , or upload files. This is the universal escape hatch for any application-level lockout.

Database management in the control panel. You can access phpMyAdmin directly from the Hostney control panel without needing SSH. This means you can run the SQL queries described in this article (password resets, role fixes, plugin deactivation) through a browser interface, even if you have never used a command line.

Automatic backups. If a lockout is caused by a compromise or a catastrophic plugin conflict, restoring from a backup is often the fastest path back. Hostney maintains automated backups that you can restore from the control panel without contacting support.

No login URL obscurity needed. Since bot traffic is handled at the server level, there is no reason to hide your login URL with a plugin. That eliminates Cause 6 entirely – you will never forget a custom login URL because you never need one. And even if you did install such a plugin, the Admin login button in the control panel would still get you in.

Summary#

WordPress admin lockouts have seven common causes: forgotten passwords, security plugin IP blocks, server-level rate limiting, plugin conflicts breaking the login page, corrupted user roles, forgotten custom login URLs, and site compromises. The fix for every single one of them requires access outside of WordPress itself – either SSH, SFTP, or a hosting control panel with database access.

The fastest diagnostic path: try logging in, note the exact error or behavior, then check whether the problem is your credentials (wrong password), your IP (blocked), or the login page itself (broken). From there, the specific fix is usually a single WP-CLI command, an SFTP folder rename, or a SQL query.

Keep a password manager, maintain SFTP access credentials separately from your WordPress login, and make sure you have a recent backup. With those three things in place, any lockout is a five-minute fix rather than a crisis. For a broader reference on WordPress issues, see How to fix the most common WordPress errors.

Related articles