PHP 8.3.14 本身无文件包含漏洞，风险源于代码中用户可控的 include/require 参数；需检查日志、配置（allow_url_include=Off、open_basedir）、代码白名单校验及 WAF 拦截情况。
PHP 8.3.14 本身不引入文件包含漏洞，但若代码中使用了 include、require、include_once 或 require_once 且参数受用户控制（如 GET/POST 参数拼接进路径），就可能触发本地/远程文件包含（LFI/RFI）。排查重点不是 PHP 版本，而是代码逻辑、配置限制与运行时环境是否被绕过。
确认是否真为文件包含行为
先区分是“误报”还是真实风险：
- 检查 Web 访问日志（如 Nginx 的
/var/log/nginx/access.log），搜索含?file=、&page=、../、%2e%2e%2f、php://filter、data://、phar://等特征的请求 - 查看 PHP 错误日志（
/var/log/php8.3-fpm.log或error_log配置路径），找类似Failed opening required '/var/www/html/../../etc/passwd'或Warning: include(): open_basedir restriction in effect的提示 - 用 curl 模拟可疑请求：
curl -v "https://yoursite.com/index.php?file=../../../../etc/passwd"，观察响应体是否返回系统文件内容或报错细节泄露路径
检查关键 PHP 配置是否生效
PHP 8.3.14 默认已收紧部分危险配置，但需人工验证是否真正启用：
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
-
禁用远程 URL 包含：确认
allow_url_include = Off（不是On）且allow_url_fopen = Off（防 RFI）。执行php --ini找到加载的php.ini，再运行php -r "echo ini_get('allow_url_include');"直接读取运行时值 -
启用 open_basedir 限制：检查
open_basedir是否设为项目根目录（如/var/www/html/:/tmp/）。若为空或为/，攻击者可遍历任意路径；若未设置，该限制即不生效 -
关闭危险流封装协议：在
php.ini中显式禁用：disable_functions = phpinfo,system,exec,passthru,shell_exec,proc_open,popen,parse_ini_file,show_source（注意：这不能替代逻辑修复，仅作纵深防御）
审查代码中动态包含点
全局搜索所有可能拼接用户输入的包含语句（尤其注意未过滤、未白名单校验的场景）：
立即学习“PHP免费学习笔记（深入）”；
- 查找
include($_GET['page']、require($template)、include 'views/' . $_POST['view'] . '.php'等模式 - 重点检查是否做了路径规范化：是否调用
basename()、str_replace(['..', '\'], '', $input)等？这些手动过滤易被绕过（如....//、%2e%2e%2f、..） - 推荐做法是白名单映射：
$pages = ['home' => 'home.php', 'about' => 'about.php']; $file = $pages[$_GET['page']] ?? 'home.php'; include $file;
验证 WAF 或服务器层是否拦截
即使代码有漏洞，WAF 可能已阻断典型攻击载荷：
- 若使用 ModSecurity + OWASP CRS，检查
REQUEST-930-APPLICATION-ATTACK-LFI.conf规则是否启用（ID 930100–930120 系列） - 云 WAF 用户，在控制台查看“文件包含防护”策略是否开启，并检查拦截日志中是否有匹配记录
- 临时关闭 WAF 测试（仅限测试环境），确认原始请求是否真能触发包含——避免误判为“WAF 误拦”而忽略代码修复
