PHP2Shell 修复后，还需核查实际运行环境与会话配置

应对 PHP2Shell 的网站运维人员需要确认实际处理网页请求的 PHP 运行环境，即使内容管理系统已经更新。PHP 于2026年10月21日发布修复；10月23日又公布了一项触发条件较窄的会话提示，结束整改前也应核查。

The Verge 10月22日的报道促成了本文的跟进。技术说明来自 PHP 项目公告及英国国家网络安全中心（NCSC）的指引，TechKili 未进行漏洞利用测试。

找到应用背后实际处理请求的运行环境

两个漏洞都涉及 PHP 对请求内存的处理。CVE-2026-109618与内存不足错误后不完整的内部状态有关；CVE-2026-109619则涉及某些状态在对应请求内存释放后仍然保留。两者都可能让未经身份验证的攻击者远程执行代码。

因此，维护范围延伸到了网站应用代码之下。第一份公告记录了针对 Apache mod_php 的有效攻击，可在应用代码开始运行之前触发。公告还根据源码分析认为 PHP-FPM 也可能受影响，同时指出尚未针对该漏洞演示完整的 FPM 利用。不同执行方式的证据程度不同，不等于可以免于修补。

PHP 发布公告列出的修复版本为 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。发行版及长期支持供应商可能提供回移补丁，因此应结合供应商公告判断，不能只看版本号。PHP 8.1 及更早分支已不再获得项目的常规更新。

使用托管网站服务时，应要求主机商说明实际承载网页流量的运行环境是否已修复。基础设施团队则应把每项服务与其使用的软件包对应起来，并确认工作进程运行的是更新后的构建。只检查命令行中的 PHP 安装，可能仍无法回答这个问题。

按具体条件理解10月23日的会话提示

PHP 的10月23日信息公告描述了另一个概率较低的远程代码执行路径，编号为 CVE-2026-115560。它要求会话上传进度功能仍然开启，并出现一种不常见的操作：应用将配置中的 php_binary 或 php_serialize 会话序列化处理器，在运行时改为 php，随后调用 session_start()。

PHP 建议在下一个常规错误修复版本发布前，设置 session.upload_progress.enabled=0。公告表示，从不在运行时切换序列化处理器的应用可以保留此功能。如果此前已按10月21日的指引关闭它，PHP 表示应继续保持，无需为这项措施再作变更。

这项后续提示应与运行环境更新一并评估。笼统声称所有安装补丁的网站仍可被利用，会超出 PHP 所描述的触发条件。

将暴露整改与入侵调查分别记录

NCSC 10月21日的指引要求优先发现 PHP 安装、更新面向互联网的系统，并关注在产品中捆绑 PHP 的供应商公告。若无法及时更新或缓解，应考虑让受影响系统暂时离线，并检查是否存在入侵迹象。

对运维人员而言，应分别保存两类记录：一类证明已处理存在漏洞的运行环境，另一类记录变更之前是否发生过入侵的调查。成功更新并不能证明此前暴露的服务从未被入侵；同样，公布漏洞也不代表某个具体网站已经受到攻击。

资料来源

• PHP：10月21日安全版本及23日会话提示

• PHP：内存不足导致内存损坏的公告

• PHP：陈旧全局状态漏洞公告

• NCSC：运维响应指引

• The Verge：10月22日的发现来源报道