MySQL user listing exposes governance gaps in database access

At a glance

What this is: This is a MySQL user-management guide that shows how listing users, checking grants, and reviewing hosts reveals common database access risks.

Why it matters: It matters because database access is an NHI governance problem as much as an admin task, and the same visibility, least-privilege, and lifecycle controls also shape human and autonomous identity programmes.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read StrongDM's guide to listing MySQL users and checking privileges

Context

MySQL user listing is really an identity governance exercise: who can connect, from where, and with what privileges. In practice, teams often treat database accounts as technical plumbing, then discover that wildcard hosts, shared credentials, and stale users have created a broader access surface than intended.

For NHI programmes, the pattern is familiar. Database accounts, service users, and application credentials behave like other non-human identities because they outlive the moment they were created, accumulate privilege, and are often reviewed only after something goes wrong. That makes MySQL user visibility a governance control, not just a DBA task.

Key questions

Q: How should security teams govern MySQL user accounts in production databases?

A: Treat MySQL users as governed identities, not just local administrative records. Review host bindings, grant scope, and authentication settings together, then remove wildcard hosts, shared credentials, and stale accounts. If you cannot prove who can connect, from where, and with what authority, the database is not adequately governed.

Q: Why do wildcard hosts and root accounts increase MySQL risk?

A: Wildcard hosts remove a key boundary around where a credential can be used, and root accounts remove the privilege boundary around what that credential can do. Together, they increase the blast radius of compromise and make misuse harder to contain. The safer pattern is host-specific, least-privilege access tied to a clear operational purpose.

Q: What breaks when MySQL access reviews are done only after incidents?

A: Post-incident reviews miss the accounts that should never have existed in the first place, especially stale users and overprivileged database identities. By the time an issue is detected, the account may already have been reused, copied, or left active across environments. Continuous review catches entitlement drift while it is still reversible.

Q: How do you know if database JIT access is actually working?

A: JIT access is working when privileged database access is time-bound, session-linked, and automatically revoked after the task ends. You should be able to show who requested access, what was granted, when it expired, and what actions occurred during the session. If those facts are missing, JIT is only a label.

Technical breakdown

How MySQL stores user accounts and privileges

MySQL keeps account information in the mysql.user table, including the username, host, authentication material, and privilege flags. That means user identity and authorisation are inseparable at the storage layer, which is why a simple user list can reveal whether access is tightly scoped or broadly exposed. Queries such as SELECT user FROM mysql.user and SHOW GRANTS FOR 'user'@'host' are not just administrative commands. They are the raw inputs for access review, entitlement validation, and drift detection across database identities.

Practical implication: inventory MySQL accounts against their host bindings and grant sets before you assume the database is properly governed.

Why wildcard hosts and root accounts expand database risk

A MySQL account tied to '%' can connect from any host, which removes a major boundary from the access decision. When that pattern is combined with root or similarly broad privileges, the database no longer has a meaningful identity constraint at the network or authorisation layer. The result is a larger blast radius for credential theft, lateral movement, and accidental misuse. In NHI terms, this is standing privilege plus weak binding, which is exactly the combination that turns ordinary account exposure into a system-wide access problem.

Practical implication: replace wildcard host bindings and application root access with host-specific, task-specific database identities.

How JIT access and session logs change MySQL governance

Just-in-time access and session logging shift MySQL from persistent account ownership to time-bound, attributable access. JIT limits how long a credential can be used, while session logs show who connected, when, from where, and what they did. That combination matters because database identity risk is not only about who exists in the user table, but also about whether usage can be proven and revoked cleanly. For NHI governance, this is the difference between an account directory and a control plane.

Practical implication: require ephemeral access paths and session evidence for privileged database work, especially where applications or contractors touch production data.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MySQL user listing is a governance control, not an admin convenience. The article shows that user tables, grants, and host bindings expose the real security state of a database. That matters because access review is only useful if the underlying identities are visible, attributable, and scoped. The practitioner conclusion is simple: treat database user enumeration as part of NHI governance, not an after-the-fact audit task.

Wildcard host access is a named identity-control failure, not just a configuration issue. A '%' host binding collapses the boundary that should distinguish local, application, and remote access. When combined with broad privileges, it creates identity blast radius that is hard to contain after credential exposure. Practitioners should recognise this as a host-binding failure mode that deserves redesign, not periodic review.

Stale database users show why lifecycle governance must be continuous. The article explicitly calls out deactivating stale accounts and revoking access when roles change or users offboard. That is the same lifecycle problem seen across service accounts and other NHIs: access persists longer than accountability. The practitioner conclusion is that offboarding must be attached to identity lifecycle events, not manual clean-up cycles.

Session logging and JIT access define the minimum evidence standard for database privilege. If teams cannot see who connected, what they ran, and when access ended, they are relying on hope rather than control. Centralised access with time-bound privilege gives governance teams something to review and investigate. The practitioner conclusion is to make provable access part of the operating model, not an optional audit add-on.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why database user enumeration should be tied to governance rather than ad hoc troubleshooting.
• For the lifecycle lens behind that control gap, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding should connect.

What this signals

MySQL governance will keep moving toward continuous identity review. As database access becomes more distributed across humans, service accounts, and automation, static user audits will matter less than whether teams can continuously prove who has access and why. The programme signal is clear: build database identity controls that produce evidence on demand, not just configuration snapshots.

Secret sprawl is the named concept hiding inside simple database user management. A database account is only as safe as the places its credentials and grants are allowed to persist. If your operational model still relies on manual cleanup, the next phase is to connect database access reviews to credential rotation, offboarding, and monitoring across the wider NHI estate.

For practitioners

• Inventory database identities by host and privilege scope Export mysql.user and SHOW GRANTS results into an access review workflow, then flag accounts with wildcard hosts, root-level permissions, or unexplained authentication plugins.
• Remove application dependence on root-style database access Replace shared administrative accounts with narrowly scoped identities for applications, maintenance jobs, and support workflows, and restrict each account to the exact host it must use.
• Attach database offboarding to lifecycle events Trigger account disablement, password expiry, and privilege removal when a user changes role, leaves a team, or a workload is retired so stale users do not persist in mysql.user.
• Require session logs for privileged database work Log source, time, identity, and query activity for every elevated connection, then route the records into review and investigation processes so access can be verified after the fact.

Key takeaways

• MySQL user enumeration becomes useful only when it is tied to privilege scope, host binding, and lifecycle review.
• The biggest risks in the article are standing root access, wildcard hosts, and stale accounts that remain active after roles change.
• Teams should move database access toward time-bound, logged, least-privilege control rather than relying on manual user audits.

Key terms

• MySQL User Table: The MySQL user table is the system record that stores account identity, host restrictions, authentication data, and privilege settings. In practice, it is the fastest way to see whether a database account is tightly scoped or broadly exposed, which makes it a core input to access review and entitlement governance.
• Wildcard Host Binding: Wildcard host binding lets a MySQL account connect from any source host rather than a specific system or network boundary. That flexibility often creates unnecessary exposure because the account can be used in more places than the original access intent assumed, increasing the attack surface if credentials are compromised.
• Just-in-Time Database Access: Just-in-time database access grants elevated access only for a short, task-scoped period and then removes it automatically. For database identities, the value is not only reduced exposure time but also a cleaner audit trail, because access exists only when there is a legitimate operational need.
• Session Logging: Session logging records who connected, when they connected, what system they used, and what actions they performed during the session. For identity governance, it provides the evidence needed to review privileged activity, investigate misuse, and prove that access was controlled rather than merely assumed.

Deepen your knowledge

MySQL user governance, privilege review, and lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring database access under the same discipline as the rest of your identity estate, it is worth exploring.

This post draws on content published by StrongDM: MySQL SHOW USERS: How to List All Users in a Database. Read the original.