MySQL warns that typing the password directly on the command line is insecure because other users can read it from process lists or shell history.
MySQL Error 57 EE_USING_PASSWORD_ON_CLI_IS_INSECURE means your password is visible when you include it in the mysql --password option. Remove the plaintext value and use option files, environment variables, or the interactive -p prompt to secure credentials.
Using a password on the command line interface can be insecure. EE_USING_PASSWORD_ON_CLI_IS_INSECURE was added in 8.0.13.
The server issues this warning when it detects that the mysql client was started with --password=your_password or -pyour_password. The plaintext secret is exposed to any user who can view operating-system process lists or shell history.
The warning was introduced in MySQL 8.0.13 as part of Oracle’s ongoing hardening efforts.
It appears on every connection that contains a literal password on the command line and does not block execution, but it signals a serious security gap.
The message is printed immediately after authentication when the client utility connects. It can show up in interactive shells, cron jobs, CI pipelines, and any script that embeds the password value in the command string.
Because it is a global warning, it surfaces regardless of user role or privilege set.
Even clients that authenticate successfully will still display the notice until the insecure pattern is removed.
Command-line passwords can be captured by the ps command, audit logs, accidently leaked stack traces, and shared terminal sessions.
Attackers need only milliseconds to copy the visible string and gain database access.
Eliminating the warning reduces credential-exposure surface area, helps you pass security audits, and aligns the deployment with industry best practices such as the CIS MySQL Benchmark.
Most cases stem from convenience shortcuts like using --password or -p with the literal password in automation scripts.
Hard-coded secrets in Docker ENTRYPOINT commands and systemd service files also trigger the alert.
Use the -p flag without a value to prompt interactively, store credentials in a protected option file such as ~/.my.cnf, or load them through MYSQL_PWD or a secrets manager. Each method stops MySQL from seeing a plaintext password argument.
Cron jobs should source a restricted my.cnf file. CI pipelines should inject MYSQL_PWD via masked environment variables.
Docker users should mount a secrets file instead of embedding the password in the run command.
Never embed passwords in shell history. Leverage OS permissions to protect my.cnf (chmod 600). Rotate credentials regularly and monitor login warnings in the MySQL error log or Galaxy’s query history panel.
Similar client-side warnings include ER_ACCESS_DENIED_ERROR and CLIENT_PLUGIN_AUTH. They differ by stopping authentication instead of just warning. Securing the password string often resolves multiple warnings simultaneously.
.
Using --password=Secret123 or -pSecret123 directly in the mysql command exposes the secret through system process listings.
Bash scripts, cron jobs, or CI YAML files containing the full command with a password trigger the warning on every execution.
Embedding MYSQL_PWD or the --password flag inside container entrypoints leaks secrets in orchestrator logs.
Unit files that call mysql with a plaintext password argument will display the warning and reveal credentials to any user with journalctl access.
.
No. It is a warning, not an error. Queries still run, but your password is at risk until you remove the plaintext argument.
It is safer than CLI arguments but less secure than option files. Environment variables may still leak via process environments. Use them only in ephemeral CI jobs.
Galaxy encrypts credentials locally and never places them on the command line. Add the connection once in the Connection Manager and run queries without exposing secrets.
MySQL offers no suppression flag. The only reliable fix is to stop passing the password on the command line.
.avif)
.avif){kind=logo}
