When the normal reset path is unavailable, copied snippets that create an administrator on every request are especially dangerous. Recovery should be attributable, time-limited, and reversible.
The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you use recovery email, hosting tools, or a temporary WP-CLI account change while preserving auditability and removing emergency access afterward.
Read the failure at the right layer
- The account email is obsolete or outgoing mail is failing.
- A security plugin, role change, or compromised account blocks access.
- Site URL/cookie problems make valid credentials appear invalid.
The branches are ordered to protect the strongest evidence around this possibility: the account email is obsolete or outgoing mail is failing. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Access recovery is also a security event; the goal is not merely to get one administrator back in; it is to restore the intended trust path without leaving a reusable bypass or erasing evidence of unauthorized changes; in this guide, the practical goal is to use recovery email, hosting tools, or a temporary WP-CLI account change while preserving auditability and removing emergency access afterward.
Build a clean diagnostic record
- Confirm whether the failure is password rejection, missing capability, two-factor challenge, or redirect loop.
- Review administrator users and recent changes through WP-CLI or the host’s trusted management interface.
- Check mail delivery separately before assuming the account does not exist.
- Take a database backup and record the emergency operator.
The sequence moves from observation toward intervention. Preserve the result of the final check—take a database backup and record the emergency operator—because it provides a useful comparison after the repair.
Worked diagnostic: evidence before action
Treat “The account email is obsolete or outgoing mail is failing” as a working hypothesis, not a conclusion. Establish a baseline first: confirm whether the failure is password rejection, missing capability, two-factor challenge, or redirect loop. Record both the result you expected and the result you actually saw.
A supporting result justifies a staging test of the narrowest repair: use wp user update USER --user_pass=... through a protected shell, or the host’s documented reset path. A result that contradicts “The account email is obsolete or outgoing mail is failing” is useful too: it rules out one layer without disturbing production and gives the next operator a clean starting point.
Recover one verified account through WP-CLI
Use a protected shell supplied by the host. Identify the exact administrator first; reset only that account and rotate the temporary password immediately after login.
wp user list --role=administrator --fields=ID,user_login,user_email,roles
wp user update VERIFIED_USER_ID --user_pass='TEMPORARY-UNIQUE-PASSWORD'
wp user get VERIFIED_USER_ID --fields=ID,user_login,user_email,rolesInterpretation and safety: Do not paste a real password into shared history. Prefer the host’s secret-entry mechanism, verify the account owner out of band, and review administrator roles after access returns.
Repair the cause—not the message
- Use
wp user update USER --user_pass=...through a protected shell, or the host’s documented reset path. - Restore the correct role only to the verified account.
- Remove a malicious or unknown administrator only after preserving incident evidence and rotating credentials.
Before applying “Use wp user update USER --user_pass=... through a protected shell, or the host’s documented reset path,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can log in through the canonical HTTPS URL and confirm least-privilege capabilities; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Verification checklist
- Log in through the canonical HTTPS URL and confirm least-privilege capabilities.
- Review all administrators, application passwords, sessions, and two-factor settings.
- Test ordinary password reset mail after access is restored.
One successful refresh is not closure. Keep the incident open until you can also review all administrators, application passwords, sessions, and two-factor settings, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
Keep an incident note with the verified account, operator, time, recovery channel, changed credentials or roles, and every temporary file or exception created; rotate exposed secrets and remove emergency access as part of the same change; include the result of this first observation: confirm whether the failure is password rejection, missing capability, two-factor challenge, or redirect loop.
State what was tested, including the result of “Confirm whether the failure is password rejection, missing capability, two-factor challenge, or redirect loop,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Tempting moves to avoid
- Do not leave a temporary PHP user-creation file in the web root.
- Do not share passwords in tickets or command history.
Operator record
Primary references
- WordPress hardening — official reference consulted for this guide.
- WordPress mail — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Use wp user update USER --user_pass=... through a protected shell, or the host’s documented reset path”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.