phpMyAdmin自身不触发LFI，风险源于误配setup.php、第三方插件或日志注入等间接途径；禁用并删除setup.php、清理config目录、限制open_basedir及关闭allow_url_include是关键防护措施。
phpMyAdmin 本身不直接触发文件包含，但配置或插件可能引入风险
phpMyAdmin 默认不会使用 include() 或 require() 加载用户可控路径，因此它自身不构成典型的 LFI/RCE 入口。真正危险的点在于：1）误配的自定义脚本（如把 setup.php 留在生产环境）；2）第三方插件或二次开发中硬编码了动态包含逻辑；3）通过日志注入、php://filter 等伪协议配合其他漏洞间接触发。CVE-2009-1151 就是典型——/scripts/setup.php 接收未过滤的 POST 数据写入配置文件，再被 include() 加载执行。
禁用 setup.php 并删除 config 目录是最有效的第一道防线
这个文件本该只在本地部署时临时使用，上线后必须移除。很多被黑案例都源于运维人员忘记清理。
- 检查
/scripts/setup.php是否存在于 web 可访问路径下，若存在，立即rm -f /path/to/phpmyadmin/scripts/setup.php - 确认
/config/目录不存在，或权限为755且属主非 web server 用户（如 nginx/www-data） - 如果已存在
config/config.inc.php，确保其权限为644，且内容不含用户输入拼接（如$cfg['Servers'][$i]['host'] = $_GET['h'];） - 在
php.ini中强制关闭危险配置：allow_url_include = Off、allow_url_fopen = Off（除非业务明确需要）
不要依赖 WAF 拦截文件包含类攻击
WAF 规则对 ../etc/passwd%00 或 php://filter 这类变体绕过率很高，尤其当攻击嵌套在 POST body、JSON 字段或 Base64 编码中时。真实渗透中，90% 的成功利用都绕过了云 WAF。
- 把防御重心放在代码层和配置层：所有涉及文件路径拼接的地方，必须用
basename()提取文件名，并限定白名单后缀（如仅允许.sql、.csv） - 避免在任何地方使用
file_get_contents($_GET['file'])、include($_POST['template'])这类模式 - 若需动态加载模板或导出文件，改用 ID 映射机制：
$files = ['export' => '/var/lib/phpmyadmin/exports/data.sql']; $path = $files[$_GET['id']] ?? null; - 启用
open_basedir限制 PHP 只能访问指定目录，例如：open_basedir = /usr/share/phpmyadmin:/tmp:/var/lib/phpmyadmin
日志文件包含是最隐蔽也最常被忽略的入口
攻击者把恶意 PHP 代码注入到 Apache access.log 或 MySQL general_log，再通过 phpMyAdmin 的“导入”或“SQL 执行”功能触发包含。这类攻击不依赖 include()，而是靠 LOAD DATA INFILE 或 SELECT LOAD_FILE() 读取日志内容，再结合 php://input 或 data:// 协议执行。
立即学习“PHP免费学习笔记（深入）”；
- 禁止 MySQL 的
secure_file_priv为空，设为具体路径（如/var/lib/phpmyadmin/upload/），并确保该路径不可执行 PHP - 关闭 MySQL general_log 和 slow_query_log，或将其日志文件权限设为
640且属主为 root - Apache/Nginx 日志目录权限设为
750，属组不包含 web server 用户 - 定期检查
SELECT @@global.general_log_file;和SHOW VARIABLES LIKE 'log_error';输出的实际路径
$_GET['lang'] 直接拼进 include("lang/{$lang}.php")，只要没做 basename() + 白名单校验，就等于在服务器上留了一扇没锁的门。 
