How to Change a Database Password After a WordPress Hack

Written by: Abigail Ivy
Published on:

Why changing the database password matters after a WordPress hack

If a WordPress site has been hacked, changing the database password is one of the fastest ways to cut off unauthorized access.

It protects the MySQL or MariaDB account that WordPress uses to read and write site data, including users, posts, settings, and plugin options.

This step matters because attackers often look for persistent access, not just a one-time compromise.

If they captured your database credentials from wp-config.php, server logs, backups, or a vulnerable plugin, they can continue manipulating your site until those credentials are replaced.

What you need before you begin

Before changing anything, make sure you can still access your hosting control panel, database management tool, and WordPress files.

In most hosting environments, you will use cPanel, Plesk, phpMyAdmin, or your host’s custom dashboard.

  • A secure administrator login for your hosting account
  • Access to the current WordPress files
  • Permission to edit wp-config.php
  • A current backup of files and database
  • Access to the database user management screen

If you cannot access the hosting account, contact the host immediately and ask them to suspend suspicious sessions, reset credentials, and verify whether the database user has been exposed.

How to change database password after WordPress hack

The exact interface depends on your host, but the process is similar across most systems.

You will create a new password for the MySQL or MariaDB user and then update WordPress so it connects with the new credentials.

1. Identify the WordPress database user

Open wp-config.php in your site’s root directory and find these lines:

  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_HOST

The DB_USER value is the database account WordPress currently uses.

Note the database name and host as well, because you may need them if you recreate the user or verify permissions.

2. Change the password in your hosting panel

In cPanel, look for MySQL Databases or Database Users.

In Plesk, use the Databases section.

Select the WordPress database user and generate a strong new password.

Use a long password with uppercase letters, lowercase letters, numbers, and symbols.

A password manager can generate and store it safely.

Avoid reusing any old password, even if it was only used for the database account.

3. Update wp-config.php

After changing the password in the database management panel, edit wp-config.php and replace the old DB_PASSWORD value with the new one.

Keep the database name, username, and host unchanged unless your host tells you otherwise.

Example:

define('DB_NAME', 'your_database_name');
define('DB_USER', 'your_database_user');
define('DB_PASSWORD', 'new_secure_password_here');
define('DB_HOST', 'localhost');

Save the file and confirm that its permissions remain restricted.

This file contains the credentials WordPress needs to connect to the database, so it should never be publicly exposed.

4. Confirm the database user still has the right privileges

Some hosting panels remove or reset user permissions during password changes.

Make sure the database user still has full access to the correct database, including SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, and INDEX privileges.

Without these permissions, WordPress may display connection or update errors.

5. Test the site and admin area

Load the homepage and sign in to /wp-admin.

If the site fails to load, recheck the password in wp-config.php and verify that the database host is correct.

A mismatch in any of these settings can cause the common “error establishing a database connection” message.

Should you create a new database user too?

In many post-hack cases, changing the password alone is not enough if the attacker had prolonged access.

Creating a new database user and updating WordPress to use it adds another layer of cleanup, especially if you suspect the original user name was exposed.

This is a good idea when:

  • The attacker had access for an extended period
  • Your backups may contain the old credentials
  • You want to revoke all trust in the existing database account
  • You are rebuilding the site after a severe compromise

If you create a new user, assign it to the same database with the required privileges, then update DB_USER and DB_PASSWORD in wp-config.php.

How to tell whether the hack touched more than the database password

A compromised database password is often a symptom, not the full incident.

Review the site for modified administrator accounts, suspicious plugins, altered theme files, and unfamiliar scheduled tasks or cron jobs.

  • Check WordPress users for unknown administrators
  • Inspect plugins and themes for unfamiliar files
  • Review .htaccess and wp-config.php for injected code
  • Look for recently changed file timestamps
  • Scan the site with a reputable security tool or malware scanner

If attackers changed database content, they may have injected spam links, hidden redirects, or malicious JavaScript into posts, widgets, or options tables.

That is why a password reset should be paired with integrity checks.

Other credentials you should reset after a WordPress hack

Database access is only one part of site security.

To reduce the chance of reinfection, reset every related credential that may have been exposed during the compromise.

  • WordPress administrator passwords
  • Hosting account password
  • FTP or SFTP credentials
  • SSH keys if used for deployment
  • Control panel email addresses and recovery options
  • Cloudflare, CDN, or DNS provider logins

If your host supports it, log out all sessions and revoke active tokens.

Attackers often pivot from one stolen credential to another, especially when password reuse is involved.

How to secure the database after recovery

Once the immediate password change is complete, reduce the odds of another incident by tightening the environment around the database.

Small configuration improvements can make a meaningful difference.

Use a strong secret in wp-config.php

Keep the database password unique and store it only in a trusted password manager.

Avoid saving it in shared notes, support tickets, or email threads.

Limit file access on the server

Set restrictive permissions on WordPress files and directories.

In general, wp-config.php should be more restricted than standard site files so other users on the server cannot read it easily.

Keep WordPress components updated

Update WordPress core, plugins, and themes promptly.

Many hacks begin with known vulnerabilities in outdated components, and the database password only protects the back end if the entry point is closed too.

Enable file integrity monitoring

Security plugins and host-level tools can alert you when core files change unexpectedly.

This helps you catch reinfection before it spreads through the database or file system.

When to ask your host for help

Contact your hosting provider if the password change fails, if database privileges look unusual, or if the site continues showing connection errors after you update wp-config.php.

Hosts can often confirm the correct database host, restore permissions, or identify server-side malware.

You should also ask for help if the compromise affected multiple sites on the same account.

Shared hosting environments can allow a breach in one installation to expose other databases, backups, or configuration files.

Signs the password change worked

After the update, your site should load normally, and the WordPress admin dashboard should accept your login without database errors.

More importantly, the old database password should no longer authenticate anywhere, which means any stolen copy is useless.

  • WordPress loads without database connection errors
  • /wp-admin opens normally
  • The new password is saved only in the updated wp-config.php
  • Old database credentials fail to log in
  • No unknown database users remain assigned to the site

At that point, the site is not necessarily fully clean, but one major persistence path has been removed.

That gives you a stable base for deeper malware scanning, user review, and post-incident hardening.