Locked out of wp-admin: reset your password without email

Checked 10 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 6 minutes

Case file

Symptom: Login fails, no reset email arrives, wp-admin unreachable
Cause: The admin password is unknown and the account’s email is out of reach
Fix: Reset the password with WP-CLI, or with an MD5 hash in the database
Result: Login succeeds, wp-admin loads the dashboard

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

Being locked out of wp-admin usually means one of two things: the password is wrong, or the password is right and something else is stopping the login. This guide covers the first case — the password is genuinely unknown and the reset email never arrives, because the email address on the account is one you cannot open or the site cannot send mail at all. The official password-reset documentation lists the email link first and then the server-side methods for exactly this situation, and the official logging-in handbook calls WP-CLI the recommended approach when standard recovery is not available.

This guide reproduces the break first. A disposable install had its admin password changed to a random value nobody recorded. Logging in with the old password failed, and both server-side fixes were then run and verified by logging in for real.

What you need

One of these: SSH access with WP-CLI installed, or your hosting control panel with phpMyAdmin (or another way to run SQL against the database).
The database name, from the DB_NAME line in wp-config.php, if you are going the database route.
A database backup before touching the database directly. The official handbook says the same: back up first, verify the table prefix, and make sure you are updating the intended user.

The diagnosis

1. Confirm the lockout

Try the password you have, once, and watch what happens. In the reproduction, the login attempt with the old password set no wordpress_logged_in cookie and the browser stayed on the login page — no redirect, no dashboard. That is a wrong password, and resetting it is the fix.

Two other symptoms mean the password is not the problem, and resetting it will not help: the password is accepted but the login page keeps reloading (a cookie or site-URL problem), or the login is blocked after too many attempts (a security plugin lockout). If either of those matches, stop here — this guide’s fix does not apply.

Key result: no logged-in cookie and no redirect after submitting the password means the password itself is wrong. Both fixes below change the password, so either one clears this symptom.

The fix

2. Reset the password with WP-CLI

From the site folder — the one that holds wp-config.php — list the administrators to find the right account, then set a new password. The official handbook recommends --prompt=user_pass, which asks for the password instead of putting it in your shell history:

Command — reset the admin password with WP-CLI

wp user list --role=administrator
wp user update admin --prompt=user_pass

Output

Success: Updated user 1.

The direct form, wp user update admin --user_pass='a-long-new-password', works the same way and is what the reproduction ran. Either way, WP-CLI hashes the password correctly on the way in, so there is no MD5 step to remember and nothing to tidy up afterwards.

Trap: typing the password in the command puts it in your shell history. Use --prompt=user_pass as the handbook recommends, and once you are logged in, change the password again from your own profile page.

3. Or reset it in the database

If you have no SSH access, most hosting control panels include phpMyAdmin. Open it, select the WordPress database, open the wp_users table, and edit the admin user’s row. In the user_pass field, delete the existing hash, type the new password, and select MD5 from the Function dropdown before saving. The official reset documentation walks the same clicks; the MD5 step is the part that matters — entering plain text without selecting a hashing function will not create a usable password.

The same change as SQL, which the reproduction ran directly against the database:

Command — reset the password with SQL

UPDATE wp_users SET user_pass = MD5('srm-admin-reset2!')
WHERE user_login = 'admin';

Output — the stored hash before login

user_login  hash_len  hash_start
admin       32        11281b9

MD5 on its own is not a secure way to store a password, but WordPress still accepts it as a legacy hash and replaces it with a properly secured version the first time you log in. The reproduction confirmed that: after one successful login the stored hash was 63 characters long, no longer the 32-character MD5.

Verify you are back in

Log in with the new password and check that wp-admin loads. In the reproduction, both paths were verified the same way — the login set the wordpress_logged_in cookie, wp-admin returned HTTP 200 with the Dashboard title, and the page said “Howdy, admin”:

Step	Login result
Old password after the password was changed	No cookie, stays on the login page
After `wp user update`	Cookie set, wp-admin HTTP 200, Dashboard
After `MD5()` in the database	Cookie set, wp-admin HTTP 200, Dashboard

Once you are in, go to Users > Profile and set a fresh password there. That replaces anything typed on the server, and it is also the moment to check the email address on the account — if it is an address you cannot open, fix that now, or the next lockout will need the same server-side rescue.

If that didn’t work

Try the email link first, if you skipped it

If the account’s email address is one you can open, the “Lost your password?” link on the login page is the simplest and safest method: WordPress emails a reset link to the address on the account. Check spam first if it does not arrive. The reproduction skipped this path because the test install has no working mail — the server has no sendmail — which is itself a common reason the email never arrives on a real site.

Check you reset the right user

If the new password still fails, check the username and the table prefix. The user list from wp user list shows the real usernames; the database route must use the table prefix from wp-config.php (it is not always wp_). And if the admin user itself is missing from the user list, treat that as a possible hack rather than just creating another account.

What happened

The admin password was unknown and no reset email could arrive, so the login failed with no logged-in cookie. The password was reset twice, once with wp user update and once with an MD5 hash written straight to wp_users, and both times the login succeeded and wp-admin loaded the dashboard. The MD5 hash was replaced by a longer modern hash on the first login, exactly as the official documentation says.

Where this came from

WP-CLI as the recommended approach, wp user update USERNAME --prompt=user_pass, the phpMyAdmin MD5 steps, the SQL form, and WordPress rehashing the MD5 on next login come from Logging In — Developer.WordPress.org.
The email link first, the phpMyAdmin clicks, the MD5 function dropdown, and the WP-CLI form come from Reset your password — WordPress.org.
The reset command and its output come from wp user update — Developer.WordPress.org.