验证phpMyAdmin是否受CVE-2014-8959或CVE-2018-12613影响，需先查版本号，再分别用PoC测试GIS路径和target参数绕过，升级后必须清理旧libraries/gis/目录并更新core.php中checkPageValidity()函数，同时配置Web服务器层拦截规则。
如何验证当前 phpMyAdmin 是否受 CVE-2014-8959 或 CVE-2018-12613 影响
先确认版本和漏洞面，比盲目打补丁更关键。受影响版本不是“所有旧版”，而是有明确范围的：
-
grep -r "\$this->PMA_VERSION" /path/to/phpmyadmin/ | head -n 1查版本号 - CVE-2014-8959：影响
4.0.x（4.0.10.13前）、4.1.x（4.1.14.7前）、4.2.x（4.2.12前） - CVE-2018-12613：影响
4.8.0–4.8.1，核心在index.php的target参数双重解码绕过
别只看主版本号——有些定制包改了 PMA_VERSION 却没修代码。真实风险得靠 PoC 验证：
- 访问
/libraries/gis/pma_gis_factory.php?gis_type=../../../../etc/passwd%00，返回文件内容即中招 - 访问
index.php?target=db_sql.php%253f/../../../../etc/passwd（%253f是?的双重编码），能读取即未修复 CVE-2018-12613
升级后必须清理旧 GIS 目录，否则补丁无效
很多团队升级完以为万事大吉，结果漏洞仍在。根本原因是：CVE-2014-8959 的载体是 libraries/gis/ 下的硬编码逻辑，新版虽重写了 pma_gis_factory.php，但若旧目录残留，请求仍可能命中老文件。
- 必须手动删除整个
libraries/gis/目录，再从新包完整复制过去 - 检查是否还存在废弃入口
gis_data_editor.php，它在 4.3+ 已移除，若残留需一并删掉 - 新版路由应为
?route=/gis，旧路径如gis_data_editor.php必须返回404
不清理旧目录 = 补丁打在空气上。Apache/Nginx 层拦截 gis_type=.*\.\. 只是临时缓解，不能替代这一步。
修复 index.php 中 target 参数绕过的三处关键修改
CVE-2018-12613 的根源不在过滤弱，而在校验逻辑被二次 urldecode() 破坏。官方 4.9.0+ 的修复不是加正则，而是重构校验流：
立即学习“PHP免费学习笔记（深入）”；
- 删掉
index.php第 465 行左右的urldecode($page)—— 它出现在checkPageValidity()的第二次校验分支里，纯属冗余且危险 - 在
checkPageValidity()函数开头加$page = strtok($page, '?');，强制截断问号后全部内容，防%253f类绕过 - 确认
$target_blacklist至少包含import.php、export.php，且白名单页面（如db_sql.php）必须严格全匹配，不允许带任何查询参数
只改 index.php 不够——core.php 中的 checkPageValidity() 必须同步更新，否则攻击者可从其他调用路径绕过。
Web 服务器层必须封堵典型 payload，不能只依赖 PHP 层
PHP 层修复可能被绕过（如三次编码 %25253f、双问号 %253f%253f），Nginx/Apache 规则提供兜底：
- Nginx：
if ($args ~* "target=.*%253f") { return 403; }放在 phpMyAdmin 的location块内 - Apache：
RewriteCond %{QUERY_STRING} target=.*%253f [NC]+RewriteRule ^ - [F] - 关键路径屏蔽：
location ^~ /var/lib/php/sessions/ { return 403; }，阻断 session 文件包含链
这些规则要配合 PHP 层修复一起生效。单独开任一层，都可能被高阶 payload 绕过。真正难搞的是登录态下 SQL 插入 PHP 代码再包含 session 的链式利用，必须用真实 payload 复测。
