How to Remove Default Databases and Insecure Defaults

What this check reads

For MySQL the check asks the server SHOW DATABASES LIKE 'test' through the shared myq helper; any row at all means the installer's test database still exists. For PostgreSQL it runs SELECT has_schema_privilege('public','public','CREATE') through pgq, against the postgres maintenance database, and a returned value of exactly t means the PUBLIC pseudo-role can still create objects in the public schema. MongoDB has no probe: it is always recorded as "review by hand", because its default test database needs an interactive mongosh session. The verdict then aggregates across engines - one default found anywhere gives WARN and names the defaults alongside any engines that came back clean, while no defaults on at least one assessed engine gives PASS and lists both the clean engines and the ones that could not be audited.

When it applies

Runs per engine detected. The MySQL branch needs MYOK=1 (root socket access), the PostgreSQL branch needs PGOK=1; without them that engine is listed as "not audited" rather than judged. MongoDB is never assessed - it is always reported as needing a manual mongosh review - and Redis has no branch at all. The PostgreSQL probe runs only in the postgres maintenance database, so per-database public grants elsewhere in the cluster are not examined. A host with an engine present but nothing assessable produces SKIP, which is not a pass.

What each result means

Why it matters

• MySQL's historical test database came with grants in mysql.db allowing any user (including anonymous) to create tables in any database named test or test_%. mysql_secure_installation removes it. CIS MySQL "Ensure the 'test' database is not installed".
• PostgreSQL before 15 let every role CREATE in public. This enables search-path hijacking (CVE-2018-1058): a low-privilege role creates a function or operator that a superuser later calls. PostgreSQL 15 removed the default grant. CIS PostgreSQL "Ensure the public schema CREATE privilege is revoked".

Why it fails, and when it is wrong

• A database legitimately named test in production triggers the MySQL branch. Rename it or accept.
• The PostgreSQL probe runs in the postgres maintenance database only. Databases created before an upgrade to 15 keep the old grant even on a 15+ server, and those are not checked. Check each: psql -d <db> -c "SELECT has_schema_privilege('public','public','CREATE')".
• Some ORMs/migrations tools assume they can create in public; revoking requires granting CREATE to the application owner role explicitly.

How to fix it

-- MySQL
DROP DATABASE test;
DELETE FROM mysql.db WHERE Db='test' OR Db='test\_%'; FLUSH PRIVILEGES;
-- PostgreSQL (run in each database)
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
GRANT CREATE ON SCHEMA public TO app_owner;   -- only the role that needs it

Verify the fix

# MySQL - the test database must be gone, along with its grants:
sudo mysql -N -e "SHOW DATABASES LIKE 'test'"                       # expected: no output
sudo mysql -N -e "SELECT COUNT(*) FROM mysql.db WHERE Db LIKE 'test%'"  # expected: 0

# PostgreSQL - check EVERY database, not just the one the check looks at:
sudo -u postgres psql -X -tAc \
  "SELECT datname FROM pg_database WHERE datallowconn" | while read -r db; do
    printf '%s: %s\n' "$db" "$(sudo -u postgres psql -X -tAd "$db" -c \
      "SELECT has_schema_privilege('public','public','CREATE')")"
  done
# expected: f for every database

Debugging

Sources

• MySQL 8.4: mysql_secure_installation (removes test DB)
• MySQL 8.4: Grant Tables, mysql.db
• PostgreSQL: Schemas and the public schema pattern
• PostgreSQL 15 release notes (public schema CREATE removed)
• PostgreSQL wiki: A Guide to CVE-2018-1058 Protect Your Search Path
• PostgreSQL: has_schema_privilege
• MongoDB: databases and the default test database

How the script reads this