根本原因是MySQL的mysql.user表权限未收紧，用户拥有UPDATE权限即可修改他人密码；phpMyAdmin仅提供SQL操作界面，不干预底层权限逻辑；必须用高权限账号执行REVOKE UPDATE ON mysql.*、回收GRANT OPTION等并FLUSH PRIVILEGES。
phpMyAdmin 里用户改别人密码的根本原因
不是 phpmyadmin 本身有问题，而是 mysql 的 mysql.user 表权限没关严——只要用户有 update 权限到 mysql 库，就能直接 update 其他用户的 authentication_string 字段。phpmyadmin 只是把 sql 操作界面化了，它不拦截底层权限逻辑。
回收 UPDATE 权限的实操步骤
必须用高权限账号（比如 root）登录后执行，不能靠 phpMyAdmin 界面点点点解决：
- 先确认目标用户当前权限：
SHOW GRANTS FOR 'username'@'host'; - 重点检查是否含类似
GRANT UPDATE ON mysql.* TO ...或更宽泛的GRANT ALL PRIVILEGES ON *.* - 回收敏感权限：
REVOKE UPDATE ON mysql.* FROM 'username'@'host'; - 如果用户只需要查自己库，就只给最小范围：
GRANT SELECT, INSERT, UPDATE, DELETE ON `myapp_%`.* TO 'username'@'host';（注意反引号包裹库名通配符） - 强制刷新：
FLUSH PRIVILEGES;
为什么不能只禁用 phpMyAdmin 的“用户”页面
禁用界面只是障眼法。用户仍可通过以下方式绕过：
- 在 phpMyAdmin 的「SQL」标签页里手写
UPDATE mysql.user SET authentication_string=... WHERE User='otheruser'; - 用命令行客户端、其他 PHP 脚本、甚至 curl 发送 POST 请求调用 phpMyAdmin 的 API 接口（如果未关闭）
- 只要 MySQL 层权限开着，任何能连上数据库的通道都可能被利用
额外要堵的两个漏洞点
光收 UPDATE 不够，这两个常被忽略：
-
GRANT OPTION必须回收：否则用户可自行GRANT UPDATE ON mysql.* TO ...把权限再要回来 -
CREATE USER和DROP USER权限也要评估：它们虽不直接改密码，但能删掉原用户再重建，等效于重置 - 如果业务真需要“管理员改用户密码”，不要给全库权限，改用专用存储过程 + DEFINER 权限控制，把密码修改逻辑封装起来
权限回收这事，本质是 MySQL 层的事。phpMyAdmin 只是玻璃窗，真正锁门的是 REVOKE 命令和 FLUSH PRIVILEGES。漏掉任意一个环节，比如忘了刷权限、或者留着 GRANT OPTION，就等于门锁坏了还假装关紧了。
立即学习“PHP免费学习笔记（深入）”；
