普通用户拥有PROCESS权限会直接暴露其他线程的完整SQL语句，因INFO字段含敏感数据、明文条件及业务逻辑，且该权限绕过MySQL默认的NULL遮蔽机制，导致敏感信息可被直接读取或二次扩散。
普通用户执行 SHOW PROCESSLIST 本身不会“主动泄露”SQL，但一旦拥有 PROCESS 权限，就可能看到其他用户的完整查询语句——而这些语句里常含敏感字段（如 SELECT password, token FROM users）、明文条件（如 WHERE email='admin@xxx.com'）或业务逻辑细节。这不是功能设计漏洞，而是权限边界被误放的结果。
为什么PROCESS权限等于打开敏感信息查看开关
MySQL 的 PROCESS 权限控制的是“能否看到其他线程的运行上下文”，不是“能否执行操作”。只要用户有这个权限：
-
SHOW PROCESSLIST就不再只显示自己的连接，而是能看到所有活跃线程的INFO字段（即正在执行的 SQL） - 即使没用
SHOW FULL PROCESSLIST，只要语句本身不超默认 100 字符，照样能直接看到完整 SQL - 如果应用错误地把
SHOW PROCESSLIST输出写进日志、监控面板或调试接口，敏感 SQL 就会二次扩散 -
INFORMATION_SCHEMA.PROCESSLIST表同样受此权限控制，查这个表也等效于调用命令
INFO为NULL不代表安全，反而更危险
很多用户以为“看不到 INFO 就没事”，其实恰恰相反：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 普通用户没
PROCESS权限时，INFO强制设为NULL，这是 MySQL 的权限隔离机制，不是数据不存在 - 一旦 DBA 错误授予
PROCESS，该用户立刻能绕过这层遮蔽，直读所有线程的原始 SQL - 更隐蔽的风险：有些中间件或运维脚本会自动收集
PROCESSLIST并入库分析，若账号权限失控，整个历史快照都带敏感内容
如何验证当前用户是否已暴露在风险中
别猜，直接查权限和实际可见内容：
- 执行
SHOW GRANTS FOR CURRENT_USER;，检查输出中是否含PROCESS—— 注意不是process小写，MySQL 权限名区分大小写 - 执行
SELECT COUNT(*) FROM INFORMATION_SCHEMA.PROCESSLIST WHERE INFO IS NOT NULL AND USER != USER();，若结果 > 0，说明你当前就能看到别人正在跑的 SQL - 对比
SHOW PROCESSLIST和SHOW FULL PROCESSLIST输出差异：如果后者突然多出大量长 SQL，基本可判定你已有PROCESS权限且正被滥用
真正容易被忽略的点是：权限回收不等于风险清零。只要曾经拥有过 PROCESS，就可能已被用于导出过历史 SQL 快照；而 performance_schema.threads 这类替代方案虽然推荐，但它默认开启且不依赖权限控制——意味着只要能连上数据库，就能查到线程状态（不含 SQL），但一旦开了 performance_schema_show_processlist=ON，又回到老问题。所以关键不在“怎么查”，而在“谁该查”。
