Direct database access is an emergency recovery path for an authorised site owner when normal email and WP-CLI are unavailable. It is not a cleanup method: a compromised file, session or hosting account can undo the change.
Back up the database, identify one known owner and change the smallest possible record.
Verify authority and installation
Confirm the requester owns or administers the specific site and database. Match DB_NAME, table prefix and canonical domain in the trusted wp-config.php or hosting configuration.
Shared hosting can contain several similar databases. Editing the wrong one can lock out another site or expose its users.
Record the current time, database and verified user identity.
Take a protected snapshot
Export the relevant database before any edit and store it outside the public web root. Restrict access because the export can contain user accounts, orders and personal data.
Do not email it or leave a .sql file under public_html. Record the export source and timestamp.
Keep an untouched original and a separate working copy.
Identify the existing owner
Inspect only the fields necessary to locate a pre-verified administrator: user ID, login, email and registration context. Confirm capabilities in the matching usermeta table.
On multisite, roles can differ by blog and super-admin status is separate. Do not assume the first user ID is the current owner.
Avoid exporting password hashes or full profile metadata.
Change one password value
phpMyAdmin offers an MD5 function that WordPress can accept for a one-time reset and then rehash after a successful login. A narrowly scoped SQL form is:
UPDATE wp_users
SET user_pass = MD5('UNIQUE_TEMPORARY_SECRET')
WHERE ID = VERIFIED_USER_ID
LIMIT 1;Replace the table prefix and placeholders only after verification. Prefer parameterised or UI-supported changes where available and keep the real secret out of shared history.
Do not create a hidden administrator
Adding rows to users/usermeta is more error-prone and leaves an undocumented account. Recover an existing verified owner whenever possible.
If a temporary account is unavoidable under an approved incident process, make it identifiable, time-limited and audited. Remove it after the owner account and MFA are restored.
Never use a common "support" username across client sites.
Log in and rehash immediately
Use a clean browser and canonical HTTPS login page. Sign in once, set a strong unique password through WordPress and enable MFA.
WordPress will replace the temporary MD5 representation with its current password hash after successful authentication. Confirm the change without copying the new hash.
Revoke all sessions and unknown application passwords.
Handle multisite and custom user tables
On WordPress multisite, a network super administrator is not represented only by a normal blog role. Confirm network ownership and use supported multisite tooling before changing privileges.
Some installations define custom user/user-meta tables or share users across sites. Inspect configuration and relationships before assuming wp_users is the target.
Do not grant super-admin capability through improvised SQL. Recover a verified existing network owner and document the affected sites.
Investigate the lockout
Review user email/roles, audit logs, hosting access, authentication plugins, must-use plugins and recent file/database changes. Secure primary email, hosting and DNS accounts.
Search for persistence that resets passwords or recreates administrators. Replace untrusted code and rotate related credentials from a clean device.
Do not reopen after only fixing the database row.
Remove emergency exposure
Close phpMyAdmin or temporary database access, remove public database tools and delete protected working exports according to retention policy. Rotate database credentials if they were exposed.
Test password reset email, login/logout, forms, checkout and scheduled jobs. Monitor privileged changes.
Request specialist recovery when table prefixes, multisite or database integrity are unclear. Share managed access and redacted IDs—never SQL dumps, hashes or passwords in chat.