根本原因是phpMyAdmin在导入、日志查看等功能中接收用户可控路径参数，未经校验即传给file_get_contents、include等函数，如CVE-2014-8959、CVE-2018-12613所示；需禁用危险功能、关闭allow_url_fopen/include、设置open_basedir、Web层拦截../请求并验证防护实效。
phpMyAdmin 为什么会出现任意文件读取漏洞
根本原因不是 phpmyadmin 主动“读文件”，而是它在特定功能中（比如导入、日志查看、主题加载）会接收用户可控的路径参数，再未经校验就传给 file_get_contents、include 或 load_file() 类函数。cve-2014-8959、cve-2018-12613 等都属于这类问题——攻击者构造 ?target=../../../etc/passwd 这类参数，绕过白名单逻辑触发读取。
禁用危险功能 + 限制 PHP 文件包含行为
很多任意文件读取漏洞依赖于 PHP 的动态包含机制，必须从运行时层面掐断：
- 确认
php.ini中allow_url_fopen = Off且allow_url_include = Off—— 否则攻击者可能通过php://filter或远程 URL 触发读取 - 设置
open_basedir严格限定可访问路径，例如：open_basedir = /usr/share/phpmyadmin/:/tmp/:/var/lib/phpmyadmin/，禁止跨出该范围的任何文件操作 - 在
config.inc.php中显式关闭高危功能：$cfg['EnableGIS'] = false;、$cfg['ShowHint'] = false;（部分提示功能曾暴露路径）、$cfg['AllowArbitraryServer'] = false; - 删除或重命名
setup/目录——该目录历史上多次被用于构造 LFI 链，且默认权限常疏于管控
Web 服务器层拦截可疑路径参数
光靠 PHP 层过滤不可靠，攻击者常绕过前端校验直接发请求。必须在 Apache/Nginx 上做硬性规则：
- Apache：在虚拟主机配置中加入
RewriteCond %{QUERY_STRING} \.\./ [NC]+RewriteRule ^.*$ - [F,L]，直接拒绝含../的请求 - Nginx：用
location拦截常见敏感路径：location ~* \.(htaccess|htpasswd|ini|conf|log|sh|sql)$ { return 403; } - 特别注意
import.php和export.php的 GET 参数——这些页面常暴露filename、output_format等参数，需额外检查是否允许任意后缀或路径跳转
验证是否真被堵住：几个关键检查点
修复后务必手动验证，别只信配置文件写了就完事：
- 尝试访问
/phpmyadmin/index.php?target=../../etc/passwd，应返回 403 或空白页，而非文件内容 - 执行 SQL：
SELECT load_file('/etc/passwd');—— 如果返回内容，说明数据库用户权限过大，不是 phpMyAdmin 问题，而是 MySQL 层未限制secure_file_priv - 检查
error_log是否仍有Warning: file_get_contents(../)类报错，有则说明某处逻辑仍存在未修复的路径拼接 - 确认
config.inc.php本身不能被 HTTP 直接访问（例如通过/phpmyadmin/config.inc.php），否则所有加固都白搭
最易被忽略的是 open_basedir 和 Web 服务器路径规则的匹配精度——写错一个斜杠或漏掉实际部署路径前缀，整个防护就形同虚设。
立即学习“PHP免费学习笔记（深入）”；
