php官方明确修复版本为8.2.35、8.3.36、8.4.27、8.5.12，低于任一对应小版本即受cve-2026-109618/109619影响；须用php -r "echo php_version;"获取纯净版本号，逐版本精确比对，不可仅看主版本或忽略rc/dev等非稳定标识。
php -v 输出结果怎么快速比对 CVE 影响范围
直接看 php -v 的输出还不够，必须提取出精确的版本号并映射到两个 CVE 的修复边界。PHP 官方明确列出的修复版本是硬性门槛：8.2.35、8.3.36、8.4.27、8.5.12，低于任一对应版本即受影响。
常见错误是只比对主版本（如看到 8.2.x 就以为安全），但实际 8.2.34 就已中招；也有人误信“小版本号靠后就安全”，却忽略 8.3.35 仍低于 8.3.36，照样在射程内。
- 用
php -r "echo PHP_VERSION;"获取纯净版本字符串，避免php -v带额外文本干扰解析 - 若输出含
dev、RC、beta等字样，一律视为不受支持版本，需立即升级 - 注意多 PHP 版本共存场景：Web 服务用的可能是
/usr/bin/php-fpm，而命令行调用的是/usr/local/bin/php，必须分别检查
批量检测多个 PHP 二进制文件的 shell 脚本
服务器上常存在多个 PHP 可执行文件（如不同版本的 php、php-cgi、php-fpm），光查 which php 不够。以下脚本可遍历常见路径并自动比对：
#!/bin/bash
targets=(
"/usr/bin/php" "/usr/local/bin/php" "/opt/php*/bin/php"
"/usr/sbin/php-fpm" "/usr/local/sbin/php-fpm" "/opt/php*/sbin/php-fpm"
"/usr/bin/php-cgi" "/usr/local/bin/php-cgi"
)for bin in "${targets[@]}"; do
for path in $bin; do
if [[ -x "$path" ]]; then
ver=$("$path" -r "echo PHP_VERSION;" 2>/dev/null)
if [[ -n "$ver" ]]; then
echo "$path → $ver"粗略判断是否低于修复线（示例仅覆盖 8.2–8.5） if [[ "$ver" =~ ^8\.2\.([0-9]+)$ ]] && [[ ${BASH_REMATCH[1]} -lt 35 ]]; then
echo " ⚠️ CVE-2026-109618/109619: $ver < 8.2.35"
elif [[ "$ver" =~ ^8\.3\.([0-9]+)$ ]] && [[ ${BASH_REMATCH[1]} -lt 36 ]]; then
echo " ⚠️ CVE-2026-109618/109619: $ver < 8.3.36"
elif [[ "$ver" =~ ^8\.4\.([0-9]+)$ ]] && [[ ${BASH_REMATCH[1]} -lt 27 ]]; then
echo " ⚠️ CVE-2026-109618/109619: $ver < 8.4.27"
elif [[ "$ver" =~ ^8\.5\.([0-9]+)$ ]] && [[ ${BASH_REMATCH[1]} -lt 12 ]]; then
echo " ⚠️ CVE-2026-109618/109619: $ver < 8.5.12"
fi
fi
fidone
done
这个脚本不依赖外部工具，纯 Bash 实现，适合在无 Python/Perl 的最小化系统上运行。它不会尝试连接网络或调用 API，所有判断基于本地二进制文件的实际输出。
- 注意正则匹配仅覆盖 8.2–8.5，如需检查
7.4或8.0，需补充对应分支并引用官方 backport 分支说明 - 脚本中
符号必须用 HTML 实体 <code><，否则会被解析为标签——这点容易在复制粘贴时被忽略 - 输出中的
⚠️是视觉提示，不影响逻辑，删除也不影响检测准确性
为什么不能只查 phpinfo() 页面
phpinfo() 页面显示的是 Web 服务器模块加载的 PHP 版本，但它可能和命令行、cron、后台任务实际调用的版本完全不一致。尤其在使用 cPanel、Plesk 或自定义 FPM pool 配置时，一个服务器上跑着 3–4 个不同 PHP 版本是常态。
- 攻击者可通过
cron调用的旧版php二进制、或通过exec("php /tmp/exploit.php")绕过 Web 层限制，直击未修复的运行时 -
phpinfo()页面本身如果未及时删除，会泄露完整配置，包括disable_functions是否绕过成功的关键线索 - 某些容器环境（如旧版 WordPress 官方镜像）里，
phpinfo()显示的是构建时版本，而运行时已被覆盖为另一个版本，造成误判
检测脚本上线前必须验证的三个点
任何自动化检测脚本在生产环境运行前，都得确认它不会触发异常行为或留下痕迹。这次漏洞的特殊性在于：部分 PoC 利用内存耗尽路径，而检测脚本若调用不当，可能意外触发相同路径。
- 确保脚本中所有
php调用都加了-n参数（禁用php.ini），避免因加载了危险扩展（如imap、exif）导致进程崩溃 - 不要在脚本中使用
php -m，某些受影响版本下该命令会触发初始化路径中的漏洞点 - 避免在循环中高频调用
php -r，建议加sleep 0.1间隔，防止被误判为扫描行为而触发 WAF 或监控告警
最稳妥的做法是先在一台测试机上运行脚本，观察 dmesg | tail 是否出现 segfault 或 out of memory 日志——这说明脚本本身已踩中漏洞触发条件，必须调整后再用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
