Skip to main content

SEC.AUTH.ROLE_ANONYMOUS_NO_PASSWORD — No name required, and no password either

  • Category: security
  • Severity: critical
  • Level: 0
  • Confidence: deterministic
  • Downtime class: none — the finding is about an account, not about a statement
  • Stability: stable
  • Suites: audit
  • Applies to: MySQL 8.4

There is no step to get past​

The empty user name means a client from a matching host picks whatever name it likes — an account row with an empty User matches any name the server does not otherwise know. The empty credential means nothing is then asked of it.

Neither half requires the attacker to know anything, and there is no second step to detect. This is the worst account state this package can report.

Bad​

-- No name required, and no password either.
CREATE USER ''@'localhost';

Good​

-- There is no configuration that makes this safe. Remove it.
DROP USER ''@'localhost';

Unlike most findings in this catalog, there is no second option. An anonymous account with a password is at least arguable; this one is not.

One finding, not two​

An anonymous account with no password could be described by three rules — this one, SEC.AUTH.ROLE_ANONYMOUS and SEC.AUTH.ROLE_NO_PASSWORD. You get one.

That is a deliberate decision rather than a happy accident: results are deduplicated by rule id and location, so two ids about one account are two findings that both survive, and the reader is left to work out that they name the same thing. The narrower statements yield to this one, which says strictly more.

What is not reported​

The same exclusions as its sibling: PostgreSQL by construction, the engine's own system accounts, and an account whose record could not be read — as undetermined, never as a clean bill.