不能靠改配置修复旧版phpMyAdmin的CSRF漏洞，因为checkToken()硬编码在common.inc.php入口处，跳过它会使import.php等敏感接口裸奔；$cfg['CheckConfigurationPermissions']仅控制文件权限，与CSRF无关；token逻辑分散多文件，手动补丁极易遗漏。
phpMyAdmin 的 CSRF 防护不是靠手动配置开关实现的，而是由版本内置机制强制生效的。低于 5.2.2 的版本无法安全防护 CVE-2023-38023，必须升级——这是唯一可靠解法。
为什么不能靠改配置来修复旧版 phpMyAdmin 的 CSRF 漏洞？
有人试图通过修改 $cfg['CheckConfigurationPermissions'] 或注释掉 checkToken() 来“绕过报错”，这反而会彻底关闭防护。真实情况是：
-
checkToken()被硬编码在libraries/common.inc.php入口处，跳过它等于让所有import.php、tbl_drop.php等敏感接口裸奔 -
$cfg['CheckConfigurationPermissions']只控制配置文件权限检查，和 CSRF 完全无关 - token 校验逻辑分散在
Token.php、common.inc.php、各 action 文件中，补丁极易遗漏
升级到 5.2.2+ 后仍出现 “Token mismatch” 怎么办？
这不是漏洞没修好，而是环境没对齐。新版 token 绑定会话 ID 与 IP 哈希前缀，依赖会话一致性。常见原因有：
-
session.save_path权限错误：Web 服务器用户（如www-data）必须对该目录有读写权，否则每次请求都新建会话，token 不可能匹配 -
session.cookie_httponly和session.cookie_samesite设置冲突：若设为Strict但访问域名跨子域（如从admin.example.com访问phpmyadmin.example.com），浏览器会拒发 cookie - 反向代理未透传 Cookie：Nginx 缺少
proxy_pass_request_headers on;，或 Apache 没开ProxyPreserveHost On，导致后端收不到原始 cookie
临时缓解措施（仅限无法立即升级的场景）
这不是修复，只是压缩攻击窗口。必须配合升级计划使用：
立即学习“PHP免费学习笔记（深入）”；
- 将
$cfg['LoginCookieValidity'] = 60;（单位秒），缩短会话 Cookie 有效期 - 确认 PHP 版本 ≥ 7.4 —— 5.2.2 已不支持 7.2 及更低版本
- 禁用所有非必要功能：如关闭
$cfg['Servers'][$i]['AllowNoPassword']、限制$cfg['Servers'][$i]['host']到内网地址
真正起作用的永远是那行命令：sudo apt upgrade phpmyadmin 或替换为官方 tar.gz 包。其他所有“配置技巧”，在 CVE-2023-38023 面前都是纸盾。token 生效的前提，是它被正确生成、传递、绑定并校验——而这些只在 5.2.2+ 的完整逻辑链里才成立。
