必须升级至5.2.x+，因4.9已eol、含多个未修复高危漏洞（如cve-2023-38023），其安全模型缺失token校验机制，仅调优config.inc.php无法弥补底层验证逻辑缺陷。
直接升级到 phpMyAdmin 5.2 是必须的，4.9 版本已停止维护且存在多个未修复的高危漏洞（如 CVE-2023-38023 CSRF），仅靠手动调整配置无法消除风险。
为什么不能只改 config.inc.php 就算“安全迁移”
phpMyAdmin 4.9 和 5.2 的安全模型有根本性差异：前者依赖松散的 session cookie 校验，后者强制所有敏感操作（import.php、tbl_drop.php、user_password.php）校验绑定会话 ID 与 IP 哈希前缀的 token。你改再多 $cfg 参数，也补不上底层验证逻辑缺失这个洞。
-
$cfg['blowfish_secret']在 4.9 中仅用于 cookie 加密，而 5.2 中它参与 token 签名，留空或弱值会导致Token mismatch -
$cfg['LoginCookieValidity']设为 60 秒在 4.9 中只是缩短会话，但在 5.2 中是 token 有效期的一部分，必须与session.gc_maxlifetime对齐 - 4.9 的
libraries/common.inc.php没有checkToken()入口调用，补上等于重写半套逻辑，极易出错
升级前必须确认的三项硬性条件
跳过任一检查，升级后大概率出现白屏、反复跳登录页或 Token mismatch 错误，不是配置问题，而是环境不兼容。
- PHP 版本 ≥ 7.4 —— 5.2.2 已彻底放弃对 PHP 7.2/7.3 的支持，
mbstring和json扩展必须启用且版本匹配 -
session.save_path目录可写 —— Web 服务器用户（如www-data）必须对该路径有读写权限，否则每次请求生成新会话，token 无法延续 - Web 服务器透传 Cookie 头 —— Nginx 需确认
proxy_pass_request_headers on;；Apache 需确认ProxyPreserveHost On，否则后端收不到原始phpMyAdmincookie
升级后立即验证的两个关键点
别只测能否登录，重点看 CSRF 防护是否真实生效。攻击面最广的操作就是导入 SQL 和删库，必须人工触发验证。
- 打开
import.php页面，抓包查看 HTML 源码里是否存在token=字段，且该值每次刷新都变化；提交时若被拒绝并返回Token mismatch，说明防护已启动 - 访问
tbl_drop.php?db=test&table=test_table（不带 token 参数），应直接 403 或跳转回登录页；若仍能显示确认页，说明checkToken()调用被绕过或禁用 - 检查
config.inc.php是否残留$cfg['CheckConfigurationPermissions'] = false;—— 这个配置和 token 完全无关，设为 false 只会让文件权限问题静默失败，绝不允许出现在生产环境
真正容易被忽略的不是升级动作本身，而是 token 机制对会话一致性的强依赖：哪怕你用的是 localhost，如果浏览器启用了「阻止第三方 Cookie」或 session.cookie_samesite=Strict，而访问路径跨子域（如从 admin.example.com 访问 phpmyadmin.example.com），token cookie 就会被拦截，导致所有 POST 操作失效。这不是 bug，是设计使然。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
