mysql_native_password Is Not Loaded: Fix ERROR 1524 on MySQL 8.4 and 9.7

Short answer: ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded means the account you log in with, or the account you are creating, uses the old mysql_native_password method, and this MySQL server does not load it. MySQL 8.4 ships with it switched off and MySQL 9.0 and later removed it. The quick fix on 8.4 is mysql_native_password=ON in the [mysqld] section of my.cnf and a restart. The lasting fix is to move each account to caching_sha2_password with ALTER USER, using the same password, before you ever upgrade to 9.x.

Applies to MySQL 8.0.46, 8.4.11 and 9.7.2 (official images, AlmaLinux 9.8 host); PHP 8.3.35 mysqlnd; MariaDB 10.6 and 10.11 checked for comparison

We reproduced every error on this page on 9 October 2026 with the official MySQL 8.0.46, 8.4.11 and 9.7.2 server images on an AlmaLinux 9.8 lab host, upgrading one data directory from 8.0 to 8.4 and from 8.4 to 9.7, and connected with the MySQL command-line client and with PHP 8.3 (mysqli and PDO). The output blocks below are copied from those runs.

Why the error appears after an upgrade

MySQL deprecated mysql_native_password in 8.0.34, switched it off by default in 8.4 and removed it in 9.0. Accounts keep the plugin they were created with, so an application user made on MySQL 5.7 or 8.0 still points at it after an in-place upgrade. On 8.4 the server starts normally, but that user can no longer log in, and the client shows the error rather than a password failure:

$ mysql -h db -u wpuser -p wpdb
ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

Creating or altering an account with the old method fails the same way, which is what breaks install scripts and control-panel tools that still ask for it:

mysql> CREATE USER 'newapp'@'%' IDENTIFIED WITH mysql_native_password BY '...';
ERROR 1524 (HY000) at line 1: Plugin 'mysql_native_password' is not loaded

This applies to Oracle MySQL and Percona Server. MariaDB is not affected: it keeps mysql_native_password as its normal method, and our cPanel and DirectAdmin lab servers on MariaDB 10.11 and 10.6 still use it for every account.

Find the accounts that still use the old method

Run this as root (or any user that can read mysql.user). Every row is an account that will fail on 8.4 without the plugin and on 9.x in any case:

mysql -u root -p -e "SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password'"

user	host	plugin
wpuser	%	mysql_native_password

On a hosting server expect one or more rows per website database user. Note the host part: wpuser@localhost and wpuser@% are two accounts, and each needs its own fix.

Quick fix on MySQL 8.4: turn the plugin back on

Add one line to the [mysqld] section of the server configuration (/etc/my.cnf on AlmaLinux, Rocky and cPanel servers; often /etc/mysql/mysql.conf.d/mysqld.cnf on Ubuntu and Debian) and restart MySQL:

[mysqld]
mysql_native_password=ON

sudo systemctl restart mysqld      # the service is called mysql on Ubuntu and Debian
mysql -u root -p -e "SHOW PLUGINS" | grep native

mysql_native_password	ACTIVE	AUTHENTICATION	NULL	GPL

In our test the old account logged in again straight away. The setting is a startup option, not a system variable, so SELECT @@mysql_native_password fails with ERROR 1193; check it with SHOW PLUGINS as above. cPanel’s own recovery steps for MySQL 8.4 also turn this option on, so on a cPanel server you may already have the line. Treat it as a bridge, not the fix: MySQL 9.x refuses to start while it is in the configuration (see below).

Lasting fix: move each account to caching_sha2_password

Change the account’s method and set the same password it already has, so the application’s configuration does not change. For a WordPress site the password is DB_PASSWORD in wp-config.php; other applications keep it in their own config file:

# Interactive client: the password is never on the command line, and the session is not saved to ~/.mysql_history
MYSQL_HISTFILE=/dev/null mysql -u root -p

mysql> ALTER USER 'wpuser'@'%' IDENTIFIED WITH caching_sha2_password BY 'the-current-password';
mysql> SELECT user, host, plugin FROM mysql.user WHERE user = 'wpuser';
mysql> exit

Type or paste the password only at the mysql> prompt. Putting it in mysql -e "..." would leave it in your shell history and, while the command runs, in the process list that other users on the server can read. MYSQL_HISTFILE=/dev/null stops the client from writing the session to its history file. MySQL 8.0 and later clients also skip lines containing IDENTIFIED or PASSWORD by default, but do not rely on that filter (other clients, such as older or MariaDB builds, may not apply it); the variable covers every client. The SELECT shows the result:

user	host	plugin
wpuser	%	caching_sha2_password

MySQL stores only a hash, so it cannot convert the old hash for you: you must supply the password in the ALTER USER statement. If nobody knows it, set a new one and update the application’s config file at the same time. Repeat for every row the query above found, then remove mysql_native_password=ON from my.cnf and restart. In our test the account kept working after that restart.

Error 2061 after the switch: “Authentication requires secure connection”

caching_sha2_password never sends the password in clear text. Over TLS or a local socket that is automatic. Over a plain TCP connection, the first login after each server restart needs the server’s RSA public key, and clients built on the MySQL C library (the mysql command, Python mysqlclient, older Perl DBD::mysql and similar) refuse unless you allow that:

$ mysql -h db --ssl-mode=DISABLED -u wpuser -p wpdb
ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.

Any one of these fixes it. Our tests confirmed each:

• Use TLS. MySQL 8.4 creates certificates on first start and clients use TLS by default; in our test the same login over the default connection worked (cipher TLS_AES_128_GCM_SHA256). Remove any --ssl-mode=DISABLED or ssl=0 from the client settings.
• Fetch the public key. Add --get-server-public-key on the command line, or get-server-public-key under [client] in the client’s option file. After one successful login the server caches the password and later logins work even without it, until the next restart.
• Use the local socket (localhost instead of 127.0.0.1) for applications on the same server.

PHP is usually fine. PHP 8.3 with mysqlnd, both mysqli and PDO, logged in over plain TCP right after a server restart in our test, because mysqlnd fetches the key itself when the OpenSSL extension is present. That covers WordPress, Joomla, Drupal and most PHP applications on shared hosting.

Before you upgrade to MySQL 9.7

MySQL 9.x has no mysql_native_password at all. If the line is still in my.cnf, the server does not start:

[ERROR] [MY-000067] [Server] unknown variable 'mysql-native-password=ON'.
[ERROR] [MY-010119] [Server] Aborting

Once the line is removed, 9.7 starts, but every account still on the old method fails with ERROR 1524 until you run the ALTER USER fix above. There is no easy way back: after 9.7 has upgraded the data directory, starting MySQL 8.4 on it fails with Invalid MySQL server downgrade: Cannot downgrade from 90702 to 80411, so a rollback means restoring a dump or a snapshot.

This is not theoretical. On 21 and 22 April 2026 a change in Oracle’s package repository let nightly updates install MySQL 9.7 on cPanel servers running 8.4, and many sites lost their database connections until administrators reverted. cPanel’s advice afterwards is to lock the packages so the system updater cannot change the major version:

sudo dnf install -y python3-dnf-plugin-versionlock
sudo dnf versionlock add 'mysql-community-*'
dnf versionlock list

Our checklist before any MySQL major upgrade:

• Take a full dump (mysqldump --all-databases --routines --events) and, if you can, a snapshot of the server.
• Run the account query above and move every account to caching_sha2_password while you are still on 8.4.
• Remove mysql_native_password, default-authentication-plugin and other options the new version no longer accepts from my.cnf.
• Test the application’s login, including cron jobs and scripts that use the mysql command over TCP.
• Upgrade on a test copy first; there is no in-place downgrade.

mysql_native_password is not loaded at a glance

Official documentation: MySQL 8.4: Native Pluggable Authentication, MySQL 8.4: Caching SHA-2 Pluggable Authentication, cPanel: MySQL 8.4 upgraded to MySQL 9.7 during nightly updates.

Related guides: MySQL 8.4 vs 9.7 LTS: what hosting admins need to know · MySQL 8.0 End of Life: Safe Move to 8.4 or MariaDB · caching_sha2_password MariaDB 12: Fix MySQL 8 Client Problems · MySQL/MariaDB won’t start: crash recovery runbook.

Frequently asked questions

Reading a lot of our guides? Go ad-free with srvScripts Pro for $6 a month. It also pays for new guides. Cancel any time.