PHP 8.3.36已修复CVE-2026-109618和CVE-2026-109619漏洞，需确认php-fpm -v显示8.3.36、session.upload_progress.enabled=Off、memory_limit≥128M或为-1，并重启服务。
直接验证 PHP 8.3 环境中文件上传相关漏洞（特别是 CVE-2026-109618 和 CVE-2026-109619）是否修复，不能只看“上传功能还能不能用”，而要聚焦于漏洞触发路径是否真正被切断。这两个漏洞不依赖上传逻辑本身，而是利用 PHP 内核在处理 multipart 请求、内存耗尽或会话状态残留时的底层缺陷。因此，验证核心是确认补丁已生效、高危配置已禁用、且无残留攻击面。
确认 PHP 版本已升级至 8.3.36
这是最基础也最关键的一步。仅升级 Web 服务器或重启 PHP-FPM 不代表版本已更新。
- 在网站根目录新建临时文件 version.php，内容为
<?php phpinfo(); ?>，通过浏览器访问并查看 PHP Version 行，确认显示为 8.3.36 - 同时在服务器终端执行
php-fpm -v（或php-fpm8.3 -v），输出必须为 8.3.36；注意：php -v查的是 CLI 版本，与 Web 环境无关 - 若使用 Docker，需进入容器内执行
php-fpm -v，不能只看镜像标签
检查关键缓解配置是否生效
即使版本正确，若未重启服务或配置未加载，漏洞仍可能被利用。重点验证两项官方推荐的缓解项：
- 执行
php-fpm -i | grep session.upload_progress.enabled，返回值应为 session.upload_progress.enabled => Off - 执行
php-fpm -i | grep memory_limit，确认 memory_limit 值不是极小值（如 16M 或 32M），理想情况是设为 -1（无限制）或至少 ≥128M —— 这能规避 CVE-2026-109618 的 OOM 触发条件 - 所有修改必须伴随完整重启：
systemctl restart php-fpm（或对应服务名），不可仅 reload
模拟请求级探测（谨慎操作）
不建议在生产环境直接发送 PoC，但可通过可控方式观察服务响应是否符合修复特征：
PHP 8.5.12
下载
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
立即学习“PHP免费学习笔记（深入）”；
- 构造一个超长字段名的 multipart POST 请求（例如 name 字段含 5000 个嵌套中括号
data[...][...][...]），使用 curl 或 Burp 发送；修复后应返回 413（Payload Too Large）或 500（内部错误），**不应出现进程崩溃、空响应或 200 成功回显** - 检查响应头中 X-Powered-By 是否仍暴露 PHP 版本；若暴露，说明 phpinfo 页面或调试信息未清理，存在信息泄露风险，虽不直接导致 RCE，但会降低攻击门槛
- 对使用 session.upload_progress 的表单（如大文件上传进度条），提交时移除
PHPSESSIDCookie 并重复发送两个快速请求，修复版本下不应出现内存异常或非预期行为
排查第三方组件是否引入旧版 PHP 运行时
常见盲区：CMS 或框架自身打包了 PHP 解释器（如某些 Windows 一键包、旧版 XAMPP、自建 Dockerfile 中固定了旧镜像）。
- 检查网站后台或 CMS 关于页面，是否有独立 PHP 版本标识（如 WordPress 插件页底部、ZZCMS 系统信息页）
- 搜索项目目录中是否存在
php.exe、php-cgi或bin/php等可执行文件，并对其运行./php -v - 若使用 Nginx + PHP-FPM，确认
fastcgi_pass指向的是系统全局 php-fpm，而非某个私有路径下的旧实例
验证不是一次性的动作。补丁发布至今仅一周，已有在野利用迹象，中小站点尤其容易因多环境共存、配置遗忘或容器未重建而遗漏。重点盯住版本号、session.upload_progress 开关、memory_limit 设置这三项，基本就能排除绝大多数 php2shell 风险。
