Skip to main content
GrN.dk

Main navigation

  • Articles
  • Contact
  • Your Digital Project Manager
  • About Greg Nowak
  • Services
  • Portfolio
  • Container
    • Excel Freelancer
    • Kubuntu - tips and tricks
    • Linux Apache MySQL and PHP
    • News
    • Image Gallery
User account menu
  • Log in

Breadcrumb

  1. Home

WordPress Admin Lockout: A Safe Recovery Guide

By Greg Nowak. Last updated 2026-07-16.

A WordPress admin lockout rarely calls for a clever hack. It calls for a controlled recovery. The account may belong to a former employee, its recovery email may be inaccessible, or a plugin failure may have taken the login screen down. Whatever the cause, the business priority is the same: restore the right person’s access without damaging the live site, creating an undocumented administrator, or weakening security.

Work from the least invasive option to the most invasive: use the normal password reset when possible, prefer WP-CLI when you have shell access, and edit the database only when it is genuinely the last route in. Before changing anything, take a database backup or hosting snapshot and confirm that you are working on production—not a similarly named staging site.

Choose the narrowest recovery route

Situation Best first action Reason
The account email still works Use “Lost your password?” WordPress completes the reset through its normal workflow.
You have shell access Use WP-CLI The update goes through WordPress rather than bypassing it.
Only the recovery email is wrong Update the email, then use the normal reset This avoids changing the password unnecessarily.
Only database access remains Make one targeted SQL change A narrow change is easier to verify and reverse.
A sensible escalation path for recovering access to a live WordPress site.

Use WP-CLI when shell access is available

WP-CLI is usually the cleanest operational route because WordPress performs the user update. Start by identifying the correct administrator. Do not assume user ID 1 belongs to the current owner.

wp user list --role=administrator \
  --fields=ID,user_login,user_email \
  --format=table

If the email address is obsolete, update it first. That may be enough to restore the standard password-reset process:

wp user update 42 \
  [email protected] \
  --skip-email

If a password change is still necessary, let WordPress store it through its current password-handling system:

wp user update 42 \
  --user_pass='A-new-long-unique-password'

Treat that password as a placeholder, not something to copy literally. Command arguments may be retained in shell history or exposed by server logging, so use an approved secure-input or secret-management method when the environment provides one. Keeping the notification email enabled for a password change can also provide a useful security signal to the account owner.

On multisite or multidomain installations, target the intended site with --url=https://example.com. The user-list command supports --network when a network-wide inventory is required. If broken site code prevents WP-CLI from loading, try the global --skip-plugins and --skip-themes flags. Must-use plugins still load, so these flags do not isolate every extension.

Use SQL only when it is the remaining door

Direct database work bypasses normal application controls and cache handling. Confirm the database, table prefix, and intended user before editing. Many installations do not use the default wp_ prefix.

SELECT ID, user_login, user_email
FROM yourprefix_users
ORDER BY ID;

If the problem is simply an unreachable email account, check that the new address is not already assigned to another user. Then make that single change and use the normal password-reset flow:

UPDATE yourprefix_users
SET user_email = '[email protected]'
WHERE ID = 42;

Verify the affected row immediately. If the change does not appear in WordPress, a persistent object cache may need to be cleared through the hosting platform. Do not alter roles or capabilities unless you have established that authorization—not authentication—is the actual problem.

MD5 is an emergency bridge, not the recovered state

Older WordPress recovery instructions commonly recommend writing an MD5 value into user_pass. WordPress retains compatibility with legacy hashes, but since WordPress 6.8 it uses bcrypt-based password hashing by default. An MD5 database update should therefore be reserved for a situation where no safer recovery route is available.

UPDATE yourprefix_users
SET user_pass = MD5('temporary-unique-password')
WHERE ID = 42;

If you must use this fallback, log in and promptly set another new, unique password through wp-admin or WP-CLI. That sends the password through WordPress’s current hashing path and replaces the temporary credential, which may remain in database-client history or operational logs. Never reuse it on another service.

Close the incident properly

Regaining access is only half the job. A professional recovery leaves ownership clearer than it was before the lockout.

  • Confirm that the account belongs to a named person or accountable business role.
  • Remove emergency administrators and other temporary credentials.
  • Review all current administrators and remove access that is no longer required.
  • Store recovery details in the team’s approved password manager, not email or chat.
  • Document the production host, account owner, recovery email, and handover contact.
  • Test the normal password-reset route after the incident.

If the lockout was unexplained—or you discover an unfamiliar administrator—treat it as a possible security incident rather than a simple password problem. Preserve relevant logs and review hosting, SFTP, deployment, database, and WordPress access before declaring the matter closed.

Keep integrations separate from human logins

Scripts, reporting tools, and external services should not share a person’s administrator password. WordPress Application Passwords provide individually revocable credentials for API access over HTTPS. Create one descriptive credential per integration and revoke it when the tool or supplier is retired. Application Passwords are for programmatic access; they cannot be used for an interactive wp-admin login.

Most repeat lockouts come from unclear ownership rather than WordPress itself. Add access review to employee and agency offboarding, maintain accountable recovery contacts, and include credentials in every website handover. If access ownership or emergency procedures have become muddled, Greg can help you regain control and establish a process your team can maintain.

Related on GrN.dk

  • Debug WordPress Safely on a Live Site
  • WordPress Security Releases Still Need an Ops Runbook for Business Sites
  • AI disclosure rules belong in the CMS, not a spreadsheet

Need help with this kind of work?

Improve your WordPress access process Get in touch with Greg.

Sources

  • wp user list – WP-CLI Command
  • wp user update – WP-CLI Command
  • Reset your password – WordPress.org Documentation
  • wp_check_password() – WordPress Developer Resources
  • Application Passwords – WordPress Advanced Administration Handbook
Last modified
2026-07-16

Tags

  • wordpress
  • WP-CLI
  • Website Operations
  • security
  • admin access

Review Greg on Google

Greg Nowak Google Reviews

 

Illustrated infographic summarizing: The EU’s August AI Deadline Reaches Bots and Synthetic Content
The EU’s August AI Deadline Reaches Bots and Synthetic Content
2026-07-16

Article 50 applies from 2 August 2026. Businesses need to map AI touchpoints, clarify ownership, and put workable transparency controls in place.

Illustrated infographic summarizing: A Voice Agent Is Only Ready When the Human Handoff Works
A Voice Agent Is Only Ready When the Human Handoff Works
2026-07-15

A practical guide to voice agents that recognise failure, pass useful context to staff, protect customer data, and improve resolution after launch.

Illustrated infographic summarizing: If the Facts Need JavaScript, AI Search May Miss the Full Page
If the Facts Need JavaScript, AI Search May Miss the Full Page
2026-07-14

A practical guide to finding and fixing JavaScript rendering gaps that can hide services, prices, contact details and metadata from AI search crawlers.

Illustrated infographic summarizing: Search Console Can See Social Posts—Your Reports Need a New Map
Search Console Can See Social Posts—Your Reports Need a New Map
2026-07-13

Search Console now reports how social posts perform across Google. Here’s a practical way to manage properties, permissions, baselines and exports.

Illustrated infographic summarizing: WordPress 7.0 Has an AI Client. Plugins Need Their Own Guardrails
WordPress 7.0 Has an AI Client. Plugins Need Their Own Guardrails
2026-07-12

WordPress 7.0 standardizes how plugins call AI providers, while leaving developers responsible for access control, cost limits, capability checks and graceful failures.

Illustrated infographic summarizing: Google’s AI Search toggle needs a test plan, not a gut decision
Google’s AI Search toggle needs a test plan, not a gut decision
2026-07-11

Google’s AI Search control creates a measurable publishing choice. Test visibility, traffic and leads before changing the setting across your site.

Illustrated infographic summarizing: OpenAI Is Retiring Agent Builder: Save the Workflow, Not Just Prompts
OpenAI Is Retiring Agent Builder: Save the Workflow, Not Just Prompts
2026-07-10

OpenAI retires Agent Builder on November 30, 2026. Here is what teams need to preserve, how to choose a migration path, and how to cut over safely.

Illustrated infographic summarizing: AI agents need a browser policy before they start clicking around
AI agents need a browser policy before they start clicking around
2026-07-09

Browser-using AI agents can save time, but they need clear rules before they enter CRMs, CMSs, portals, or admin tools and start taking action.

Illustrated infographic summarizing: When AI writes JSON, one bad field can break the workflow
When AI writes JSON, one bad field can break the workflow
2026-07-08

Structured AI output is useful in real workflows, but teams need schemas, validation, retries, and logs before JSON reaches production systems.

Illustrated infographic summarizing: AI search is eating the click: measure the queries before rewriting pages
AI search is eating the click: measure the queries before rewriting pages
2026-07-07

AI summaries are cutting into search clicks. Start with a practical dashboard that shows query risk, bot purpose, page value, and crawler policy.

More articles
RSS feed

GrN.dk web platforms, web optimization, data analysis, data handling and logistics.