PHP 8.4.27升级后须复测四维度：运行时版本（phpinfo确认SAPI与版本）、配置实效性（session.upload_progress.enabled=0等）、路径/协议载荷拦截行为、日志中防御痕迹（如“Path traversal attempt”）。
PHP 8.4 文件包含漏洞（特指 CVE-2026-109618/109619 “php2shell”系列中涉及的路径解析与文件加载逻辑缺陷）修复后，不能仅依赖“版本升级完成”就认为风险解除。真实环境中，漏洞利用常绕过补丁、依赖配置残留或代码层疏漏。复测必须覆盖运行时行为、配置实效性、边界逻辑和业务连通性四个维度。
检查 PHP 实际运行版本与模块加载状态
很多服务器存在多版本共存、CLI 与 Web SAPI 使用不同二进制、或通过容器镜像缓存旧版本等情况。只在终端执行 php -v 不代表网页请求走的是新版本。
- 访问一个 PHP 探针页（如 info.php），调用 phpinfo()，确认 Server API 显示为 FPM/Cgi 或 Apache 2.0 Handler，且 PHP Version 与你升级目标一致（如 8.4.27）
- 检查 Loaded Modules 区域是否仍加载了高危扩展（如旧版
soap.so、imap.so），这些可能成为绕过主补丁的通道 - 在 Web 环境下执行
<?php echo PHP_BINARY; ?>，比对输出路径是否指向新安装目录（如/usr/bin/php8.4而非/usr/bin/php符号链接）
验证关键配置项是否生效且无覆盖
php2shell 漏洞的触发高度依赖特定配置组合（如 session.upload_progress、open_basedir、disable_functions）。修复后需确认这些设置不仅写入 php.ini，还被实际继承并强制启用。
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
- 用
php -i | grep -E "(session\.upload_progress|open_basedir|disable_functions)"查看 CLI 下配置；再用curl http://your-site/info.php?cfg=1（若探针支持）对比 Web 下值是否一致 - 重点验证：session.upload_progress.enabled=0（官方推荐临时缓解项）、open_basedir 是否设为合理路径（非空、非 "/"）、disable_functions 是否包含
system,exec,passthru,shell_exec,pcntl_exec等全部高危函数 - 检查是否有 .user.ini、.htaccess 或 php-fpm pool 配置（如
php_admin_value[open_basedir]）意外覆盖了全局设置
构造典型 LFI/RFI 载荷进行响应行为测试
不依赖扫描器报“未发现”，而要亲手发请求，观察服务是否真正拒绝、拦截或静默处理——这是判断补丁是否落地的最直接证据。
立即学习“PHP免费学习笔记（深入）”；
- 测试基础路径遍历：
curl "http://site.com/index.php?file=../../../../etc/passwd"，预期响应：HTTP 400/403/404，且响应体不含root:x:等敏感内容 - 测试编码绕过：
?file=%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd、?file=....//....//....//etc/passwd - 测试伪协议注入：
?file=php://filter/read=convert.base64-encode/resource=/etc/passwd，应被拦截或返回空/错误，而非 base64 编码的文件内容 - 若业务含文件包含逻辑（如
include $_GET['tpl']），务必测试所有入口点，包括 POST、COOKIE、X-Forwarded-For 等可控参数位置
审查日志与监控中的拦截痕迹
真正的修复会在运行时留下“防御动作”的日志指纹。没有日志记录的“安全”，往往是失效的。
- 检查 PHP 错误日志（
error_log配置路径）中是否出现 "Invalid path"、"Path traversal attempt"、"Disallowed protocol" 类警告（PHP 8.4.27 已增强此类日志输出） - 查看 Web 服务器访问日志（Nginx/Apache），筛选含
..%2f、php://、data://的请求，确认其状态码为 400/403/444（Nginx）而非 200 - 若有 WAF 或云防护（如 EdgeOne、腾讯云WAF），检查其拦截日志中是否命中规则 ID 4401216559 / 4494969309，且动作是“block”而非“log only”
