Skip to main content

SEC.PRIV.GRANT_PROCESS — An account can read every other session's statements

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

What leaks, precisely​

Not the session list — the statement text in it.

Any value that was interpolated into SQL rather than bound travels in that text: a password being set, a token being looked up, a customer record being written. SHOW PROCESSLIST and information_schema.PROCESSLIST show it to anybody holding PROCESS, including for connections belonging to entirely different applications on the same server.

Without the privilege, a session sees only its own rows. That difference is the whole finding.

Why medium and not high​

It reads, and only what is in flight. It changes nothing, persists nothing, and reaches nothing outside the server — which is the line between it and SEC.PRIV.GRANT_FILE. Reporting both at one level would tell you nothing about which to fix first.

What it looks like​

-- Sees the current statement of every session on the server.
GRANT PROCESS ON *.* TO 'app'@'10.0.0.%';

What to do about it​

-- The application account does not need to watch other sessions.
REVOKE PROCESS ON *.* FROM 'app'@'10.0.0.%';

-- A monitoring account is a different account, and keeps it:
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'monitoring'@'10.0.0.9';

The account SQLens connects as is never reported​

A monitoring account needs PROCESS, and so does the read-only audit account this package's own setup guidance asks you to create. A tool that reports the privileges its own documentation tells you to grant is a tool nobody trusts twice — so the exclusion is part of the rule rather than a note here.