PHP 7.4 已于2023年11月结束生命周期，当前受CVE-2026-109618等高危漏洞影响，所有7.4.x版本存在远程代码执行风险，需重点识别被CMS锁定的未升级实例。
PHP 7.4 已于 2023 年 11 月正式结束生命周期（EOL），官方不再提供安全更新。当前（2026年10月）已确认受高危漏洞 CNVD-2026-41674/CVE-2026-109618 影响，所有未升级的 PHP 7.4.x 版本（包括 7.4.33）均存在远程代码执行风险。对这类老旧站点做漏洞扫描，不能只依赖工具“扫出结果”，更要聚焦真实可利用路径与防护盲区。
重点识别“已停止维护”但仍在运行的实例
很多 PHP 7.4 站点并非主动选择，而是被 CMS 或框架“锁定”——例如旧版 WordPress（
- 执行 php -v 和 php-fpm -v（或对应版本如 php-fpm7.4 -v），区分 CLI 与 Web 环境是否混用不同版本
- 检查 phpinfo() 页面（如有暴露）中的 “System”、“Configure Command” 和 “Loaded Configuration File”，确认是否为源码编译或第三方包（如 Ubuntu 的 ppa:ondrej/php）提供，后者可能打过非官方补丁但不可信
- 通过 HTTP 响应头（如 X-Powered-By）或错误页特征反推 PHP 版本，避免仅依赖 /server-status 或探针脚本误判
不依赖通用扫描器的“默认规则”
主流漏洞扫描器（如 Nessus、Nuclei、Acunetix）对 PHP 内核级漏洞的检测多基于版本号比对，容易漏掉两类高危情况：
- 打了本地补丁但未改版本号：运维手动 patch 了 unserialize 或内存管理逻辑，但 php -v 仍显示 7.4.33，扫描器会标记“已修复”，实际仍有风险
- 运行在容器或 PaaS 中，底层 PHP 被隐藏：如阿里云虚拟主机、腾讯云轻量应用服务器预装环境，需结合进程树（ps aux | grep php）和 so 文件路径（ldd $(which php) | grep libphp）交叉验证
必须人工验证的三个高危入口点
自动化扫描无法代替对业务逻辑链路的审查。以下三类代码模式在 PHP 7.4 旧站中高频出现，且极易触发本次 RCE 漏洞：
立即学习“PHP免费学习笔记（深入）”；
-
反序列化未设白名单：检查所有
unserialize($_*调用，确认是否传入['allowed_classes' => [...]]；若无，即使 PHP 7.4.33 也完全不免疫（该参数虽原生支持，但需显式启用） -
动态文件包含未校验路径：grep 全项目
include.*\$_|require.*\$_|file_get_contents.*\$_，尤其关注 URL 参数含page=、tpl=、lang=的控制器，%00 截断、../ 绕过、phar:// 协议在 7.4 下仍有效 -
危险函数未禁用：查看 php.ini 中
disable_functions是否包含eval,assert,system,exec,passthru,shell_exec,proc_open；若为空或仅禁用部分，攻击者可通过反序列化 gadget 链调用剩余函数达成 RCE
扫描后不要止步于“发现漏洞”，要判断是否可利用
PHP 7.4 旧站常部署在弱防护环境中（如无 WAF、无日志审计、无最小权限），但并非所有漏洞都能被直接利用。需结合上下文评估：
- 若站点关闭了错误回显（display_errors=Off）、启用了 open_basedir、且所有用户输入都经
filter_var校验，则 SQL 注入或 XSS 可能仅停留在“存在”阶段 - 但本次 CNVD-2026-41674 是内核级内存破坏漏洞，只要 Web 服务可访问、PHP-FPM 进程存活，构造特定 HTTP 请求头（如畸形 Content-Length + 多重 Transfer-Encoding）即可触发，无需登录、无需交互，属于“扫描即告破”类型
- 因此，任何 PHP 7.4 站点，只要未升级至 PHP 8.2.35+ / 8.3.36+ / 8.4.27+ / 8.5.12+，都应按“高危可利用”处置，优先下线或加严访问控制（如 IP 白名单、临时 503）
