phpMyAdmin历史路径泄露漏洞的演变与当前防护

phpMyAdmin 在过去十年里屡次因「历史路径泄露」而被攻击者利用，最早可以追溯到 2014 年公开的 CVE‑2014‑8870，该漏洞让未经授权的请求直接返回 /libraries/ 目录下的源码路径，进而推断出服务器的文件结构。随后 2016 年的 CVE‑2016‑5734 将攻击面扩大到 setup/ 与 themes/，仅凭一次 HTTP GET 就能抓取完整的相对路径列表。2020 年的 CVE‑2020‑25710 更是将路径泄露与错误信息拼接，导致攻击者在 404 页面中看到 /usr/share/phpmyadmin/ 之类的绝对路径。

路径泄露的技术演进

最初的实现依赖于 phpMyAdmin 对错误页面缺乏统一过滤，开发者在调试时直接 echo 了 __FILE__ 常量。随后版本在错误处理层加入了 ob_clean()，但并未覆盖所有入口点，例如 libraries/ 下的 common.inc.php 仍保留了路径拼接逻辑。2021 年的代码审计报告显示，攻击者可以通过构造 index.php?server=1&db=information_schema 参数，触发 include() 时的相对路径回显，从而间接获得绝对路径。

当前防护的关键措施

• 升级至官方发布的最新稳定版，官方自 5.1 以后已在核心库中统一使用 realpath() 并隐藏 __DIR__ 信息。
• 在 Web 服务器层面禁用目录索引，Options -Indexes 是最简洁的 Apache 配置。
• 对 libraries/、setup/ 等敏感目录添加 Access‑Control‑Allow‑Origin: sameorigin 或直接使用 .htaccess 限制 IP。
• 启用 display_errors=Off 并在 php.ini 中强制 log_errors=On，防止错误信息泄露。
• 使用 WAF（如 ModSecurity）拦截带有 ../、..%2F 等路径遍历特征的请求。

企业在审计资产时，常会把 phpMyAdmin 放在内网的专用子域名下，配合 VPN 双因子登录；而开源项目的维护者则倾向于在 composer.json 中声明 config.platform.php，锁定兼容的 PHP 版本，防止因底层函数行为差异导致意外路径回显。细节决定成败：一次错误的 chmod 777 /var/www/html/phpmyadmin 可能让攻击者轻易读取 config.inc.php，进而拿到数据库凭证，随后利用路径泄露完成持久化。

路径不是秘密，隐藏才是防线。