Finding a Root Database Password Left in Shell History

Interactive shells keep a record of what was typed. Bash writes each command to ~/.bash_history, and the history builtin prints that list. The feature is meant to save you re-typing commands, but it has a side effect: anything you pass as an argument - including a password - is recorded verbatim and lingers long after the command finished running.

The classic offender is the MySQL client. Writing mysql -uroot -pR00t!Db_2026 shop hands the password to the program on the command line. There is no space between -p and the value, so the whole token is the credential. That line is now in the history file, readable by anyone who later operates as that user. A handful of other tools have the same flaw, which is why many of them now warn that supplying a password on the command line is insecure.

From an attacker's point of view this is one of the cheapest wins available. You do not need to read a config file, escalate privileges, or break any crypto - you just run history and read. Because sudo is a dead end in this scenario, the history is exactly the kind of low-effort, high-value artifact a real operator checks first after landing on a host.

• Hunting through files for the password. It was never written to a file here - the value only ever appeared on a command line, so history is the right tool, not cat.
• Reaching for sudo. sudo is a dead end in this scenario; the win is reading what is already readable, not escalating.
• Misreading where the password starts. The value follows -p with no space - R00t!Db_2026 - not the database name shop that comes after it.
• Assuming history is cleared. Operators rarely scrub their history; the line usually survives until someone deliberately wipes it.

The root cause is putting a secret on a command line at all. Safer patterns keep the password out of both the process list and the history file:

• Use mysql -uroot -p with no value so the client prompts interactively - the password is never typed as an argument.
• Store credentials in a protected ~/.my.cnf with chmod 600, or use mysql_config_editor to keep them in an encrypted login path.
• Prefer socket or token-based authentication so a static password is not needed for routine queries.
• Periodically clear sensitive history and set HISTCONTROL=ignorespace to keep secret-bearing commands out of the history file.

If a password has appeared in history or a process list, consider it leaked and rotate it - clearing the history afterwards does not undo a read that may have already happened.