How to fix ERROR 1131: Anonymous user can't change passwords in MySQL

MySQLBEGINNERMEDIUMUpdated Dec 23, 2025· 139 views

This error occurs when attempting to change a MySQL password while logged in as an anonymous user. Anonymous accounts lack the ALTER USER privilege required to modify passwords, preventing password changes from succeeding.

Quick fix

Fixes 1131

SELECT USER();
  1. Verify you are using an anonymous account
  2. Exit the anonymous session and reconnect as a named user
  3. Remove anonymous accounts (production cleanup)
  4. Fix --init-file password change issues
mysql — error
SELECT USER();
ERROR 1131: Anonymous user can't change passwords

What this error means

MySQL Error 1131 (ER_PASSWORD_ANONYMOUS_USER) is raised when you attempt to execute password-changing commands like SET PASSWORD or ALTER USER while authenticated as an anonymous user. An anonymous MySQL user is an account with a blank username (such as ''@'localhost' or ''@'%') that matches any connection without requiring a specific username. When you connect to MySQL without providing a username, MySQL automatically routes your connection to an anonymous account if one exists. Anonymous accounts are intentionally restricted and do not possess the ALTER USER privilege, which is required to change passwords. This is a security design to prevent unauthorized password modifications through anonymous access.

Typical symptoms

  • Connection succeeds without providing a username or password
  • SET PASSWORD or ALTER USER commands fail immediately with error 1131
  • The error message appears: "You are using MySQL as an anonymous user and anonymous users are not allowed to change passwords"
  • SQLSTATE 42000 is returned with the error
  • Password change attempts fail silently in scripts using --init-file

Common causes

  1. You are connected to MySQL using an anonymous account (blank username)
  2. Anonymous accounts in MySQL by default have no password and allow passwordless login
  3. Anonymous accounts intentionally lack the ALTER USER and SET PASSWORD privileges
  4. Default MySQL installations create anonymous accounts for local testing that must be removed before production use
  5. Using --init-file startup option to change passwords, which triggers this error due to ACL cache not being loaded

How to fix "ERROR 1131: Anonymous user can't change passwords"

1Verify you are using an anonymous account

First, confirm that you are indeed logged in as an anonymous user. You can check this by running:

sql
SELECT USER();

If the output shows something like @localhost or @% with an empty username part, you are using an anonymous account. A normal user would display username@hostname.

2Exit the anonymous session and reconnect as a named user

Disconnect from the current anonymous session and reconnect with a named user account that has ALTER USER privileges. The root user is ideal:

bash
mysql -u root -p

Enter the root password when prompted. Once connected as root, you can now change passwords for any user:

sql
ALTER USER 'someuser'@'localhost' IDENTIFIED BY 'newpassword';
FLUSH PRIVILEGES;

This is the most straightforward solution for production environments.

3Remove anonymous accounts (production cleanup)

Fresh MySQL installations include anonymous accounts by default that should be removed before production use. Connect as root and execute:

sql
DROP USER ''@'localhost';
DROP USER ''@'%';
FLUSH PRIVILEGES;

This removes both the localhost and wildcard anonymous accounts. Verify they are gone:

sql
SELECT user, host FROM mysql.user WHERE user = '';

Should return an empty result set.

4Fix --init-file password change issues

If you are encountering this error when using the --init-file startup option, MySQL is running in a state where the ACL cache is not initialized. Add a FLUSH PRIVILEGES command before attempting password changes:

sql
FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpassword';

The FLUSH PRIVILEGES statement reloads the user grant tables and initializes the in-memory ACL cache, allowing subsequent password-change commands to work properly.

5Use --skip-grant-tables recovery method

If you cannot connect with a named user, start MySQL with the --skip-grant-tables option to bypass authentication entirely:

bash
mysqld --skip-grant-tables &

Then connect without credentials:

bash
mysql -u root

Within that session, reload the grant tables and create/update a user:

sql
FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpassword';

After the password is set, stop the server and restart normally. This method is only for recovery situations, not production use.

6Ensure the user has ALTER USER privilege

If you are logged in as a named user but still receive error 1131, verify the user has the required privileges:

sql
SHOW GRANTS FOR 'youruser'@'localhost';

The output should include ALTER USER or ALL PRIVILEGES. If not, grant the necessary privilege using root:

sql
GRANT ALTER USER ON *.* TO 'youruser'@'localhost';
FLUSH PRIVILEGES;

Note: Some users may only have user-level privileges, which do not permit password changes for other users. They can only change their own password if they are authenticated with their own username.

Advanced notes

Why Anonymous Accounts Exist: MySQL creates anonymous accounts by default during installation for convenience in development environments. These accounts allow connections without credentials for quick testing. However, they are security vulnerabilities in production and must be explicitly removed.

Privilege Model: Anonymous accounts match any username but do not have special privileges. When MySQL routes your connection to an anonymous account, it treats you as having minimal permissions. The ALTER USER privilege is explicitly NOT granted to anonymous accounts.

ALTER USER vs SET PASSWORD: Both commands fail with error 1131 for anonymous users. SET PASSWORD is the older syntax (still supported in MySQL 5.7+), while ALTER USER is the modern approach (introduced in 5.7.6). Neither works for anonymous accounts.

--init-file Limitation: This is a known MySQL behavior documented in the 5.7.11 and 5.8.0 changelogs. When the server starts, the ACL cache is not initialized until FLUSH PRIVILEGES is called. Any password change command before that fails with error 1131, even if syntactically correct. This is a startup-time-only issue and does not occur during normal operation.

MariaDB Compatibility: MariaDB raises the same error 1131 with identical behavior and solutions. The fixes described here work for both MySQL and MariaDB.

Frequently asked questions

What does "1131" mean?
MySQL Error 1131 (ER_PASSWORD_ANONYMOUS_USER) is raised when you attempt to execute password-changing commands like SET PASSWORD or ALTER USER while authenticated as an anonymous user. An anonymous MySQL user is an account with a blank username (such as ''@'localhost' or ''@'%') that matches any connection without requiring a specific username. When you connect to MySQL without providing a username, MySQL automatically routes your connection to an anonymous account if one exists.
How do I fix "1131"?
This error occurs when attempting to change a MySQL password while logged in as an anonymous user. Anonymous accounts lack the ALTER USER privilege required to modify passwords, preventing password changes from succeeding.
What causes "1131"?
You are connected to MySQL using an anonymous account (blank username) Anonymous accounts in MySQL by default have no password and allow passwordless login Anonymous accounts intentionally lack the ALTER USER and SET PASSWORD privileges
Is the "1131" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading