WordPress recovery
Cannot log in to WordPress admin after a hack – what should you do?
Cannot log in to WordPress admin after a hack – what should you do?
If you cannot log in to WordPress admin after a hack, do not immediately create several administrators or delete plugin folders. First distinguish a password problem from a broken plugin, an account altered by the attacker, or active malware. Recovering access is only the beginning; it does not make the website clean.
Identify the exact failure
These symptoms point to different causes:
- the password fails and no reset email arrives;
- the username no longer exists;
- login succeeds but returns to the login form;
/wp-adminresponds with 403 or 500;- the page is blank or reports a critical error;
- the browser redirects to another domain;
- your account logs in without administrator privileges;
- a security plugin has blocked your IP address.
Record the error, timestamp and matching server-log entries. If other compromise indicators exist, follow the first 30-minute incident checklist.
Secure access outside WordPress first
An active attacker can delete every new admin you create. Change hosting and SFTP credentials from a clean device, enable multi-factor authentication, and review users of the hosting account. Check the email account too: a compromised mailbox gives the attacker access to password resets.
Capture the current files, database and logs before modifying users.
Recover access with WP-CLI
With SSH and WP-CLI, list users and inspect your account:
wp user list --fields=ID,user_login,user_email,roles,user_registered
wp user get myadmin --field=roles
Set a unique password and verify the email address:
wp user update myadmin --user_pass='A_LONG_UNIQUE_PASSWORD'
wp user update myadmin --user_email='secure@example.com'
wp user set-role myadmin administrator
Create a temporary administrator only if necessary, then remove it later. Preserve evidence about unknown accounts before deleting them. The guide to unknown WordPress administrators lists related changes worth checking.
Recover through the database
Without WP-CLI, inspect the user table through phpMyAdmin or another database tool. The prefix may not be wp_.
SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC;
Capabilities are stored in wp_usermeta. Do not paste unverified SQL from random tutorials or leave a weak MD5 password in place. Restoring the correct email and using WordPress's password-reset flow, or updating through WP-CLI, is safer. Multisite roles and super administrators require separate handling.
Login loops and redirects
A login loop can come from cookies, domain configuration or cache, but after a compromise it can also be deliberate. Check siteurl, home, HTTPS proxy settings, cookies, object cache, URL constants in wp-config.php, and login-related plugins or mu-plugins.
Renaming one suspected plugin directory over SFTP can isolate a crash. Renaming every plugin directory may hide the symptom while removing evidence about which component or payload caused it.
403, 500 and blank screens
A 403 may come from a WAF rule, .htaccess, permissions or an IP block. A 500 can indicate corrupt PHP, an incompatible update or a deliberately broken plugin. Read the PHP error log and web-server logs rather than guessing from the browser page.
Sometimes the site must first be made minimally functional through SFTP. Once the WebShield component can be installed, automated file and state analysis can begin.
Malware can hide administrator accounts
The WordPress dashboard is not a trustworthy security inventory. Malware can alter user-query hooks so that an account exists in the database but disappears from the user list. Plugins and themes can be hidden in similar ways.
Inspect the database and filesystem independently of WordPress. WebShield monitors those changes outside the dashboard, so a malicious account or component can still be detected when the UI hides it.
Access is back. Cleanup starts now
Review sessions and application passwords
Changing the password may not invalidate every access method. Inspect application passwords, API keys, XML-RPC use and active session tokens. Force logout on all devices, then restore only integrations with a known owner and purpose.
An attacker may use an application password, WooCommerce API key or compromised integration instead of a browser login. Search access logs for the sources of administrator actions, REST API traffic and XML-RPC requests.
Email and account manipulation
Verify administrator email addresses, display names and password-reset behaviour. Attackers can alter SMTP settings, disable outgoing mail or redirect notifications. Review hosting-mail forwarding rules and domain DNS records too.
The user table does not provide a simple modification timeline. Database logs, audit trails and backup comparisons are valuable. Without logs, state the limitation: the access time and method may not be provable.
Broken plugin or compromise?
A failed update can also block admin access. Chronology and related indicators separate the cases. A PHP fatal error immediately after a known update, without unknown files or users, points toward compatibility. Suspicious POST requests, a new administrator and modified core files at the same time should be handled as an incident.
Logging can be enabled temporarily without displaying errors to visitors:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
debug.log may expose paths and sensitive values. Disable it after investigation and never leave it publicly downloadable.
Harden administration after recovery
Use individual accounts, multi-factor authentication and least privilege. Do not share one administrator between an agency and client. Restrict who can install plugins or edit files. DISALLOW_FILE_EDIT reduces direct theme editing through a stolen admin account, but does not protect against a vulnerable plugin.
Alert on role changes, new administrators, password changes and email changes. Forward login logs to separate storage so the same compromised account cannot erase all evidence.
After regaining access:
- verify every administrator;
- invalidate active sessions;
- rotate security salts;
- inspect plugins, themes and mu-plugins;
- review scheduled jobs and database injection;
- compare files with clean sources;
- identify and close the entry point;
- rotate all credentials again after the site is clean.
If persistence remains, the attacker can lock you out again. Read why WordPress sites get reinfected before treating a password reset as incident closure.
On a business-critical site, the first objective is controlled recovery, not opening the dashboard at any cost. Evidence preservation, full cleanup and continued monitoring are what actually return control to the owner.