RootGS 安全观察｜发布日期：2026 年 11 月 1 日｜资料核验截至当天（UTC+8）
PHP2Shell 的难点不止是下载修复版本。一台服务器可能同时运行多个 PHP 分支、容器和 FPM 池；命令行检查正常，也不等于所有网站已经使用修复后的运行时。本文围绕 CVE-2026-109618 与 CVE-2026-109619，讨论怎样把紧急升级做成可验证的闭环。
一、为什么这次 PHP 事件值得优先处理
PHP 项目于 10 月 21 日公开两项公告，均标注 CVSS v4.0 9.2。109618 涉及内存耗尽异常引发的状态损坏；109619 涉及请求结束后残留状态被后续请求使用。二者具有远程代码执行风险。PHP：109618 公告；PHP：109619 公告。
CVE 官方记录中的 CISA 条目显示，109618 于 10 月 26 日纳入已知被利用漏洞目录。这个证据支持提高处置优先级，但不能据此断言某个站点已经失陷。CVE 记录与 CISA 标记。
二、影响判断要落到实际请求路径
不要把所有 PHP 部署方式的利用条件混为一谈。109618 公告将 mod_php 的请求启动、清理路径与 FPM 的行为分别讨论；109619 公告则说明了同一工作进程跨请求使用残留状态的条件。我们据此建议：同时盘点版本、SAPI、扩展和流量入口，不能只按服务器上有没有 php 命令来判断。
实际盘点可从域名开始：域名进入哪台反向代理、转到哪个 socket 或端口、对应哪个 FPM 池、该进程从什么路径启动。然后检查容器镜像、独立管理面板以及备用节点。没有接入主站域名的后台工具，也可能有直接访问地址。将这些关系写成清单，通常比再跑一次泛化扫描更容易发现遗漏。
三、修复版本与旧分支不能只看大版本号
两项官方公告列出的修复版本为 8.2.35、8.3.36、8.4.27、8.5.12。采用发行版维护包时，应核对供应商的安全修复记录和完整包版本，而不是把上游版本号作为唯一标准。
NCSC-NL 的运维资料还指出，PHP 项目已为 7.4、8.0、8.1 提供最小源码回移；这些分支已停止常规支持，源码回移不等于恢复长期维护。NCSC-NL 运行环境与回移说明。
对维护团队而言，应分别记录“补丁来源可信”“构建或包安装成功”“服务进程已切换”三个结论。自行编译时还要检查扩展兼容、加密库依赖和加载错误；使用托管面板时，应要求供应商明确实际生效的包版本和重载安排。
四、怎样验证升级，而不是只验证安装
建议先在与生产一致的测试环境验证登录、上传、会话保持和后台任务，再按站点分批切换。更新完成后核对进程启动时间、实际二进制路径、FPM 池配置及错误日志；长驻进程不能仅凭磁盘文件已替换就判定修复。
命令行 php -v 只能说明当前命令的解释器版本。若必须通过 Web 请求核对运行时，应使用仅管理员可访问的临时诊断入口，只返回必要的版本或构建信息，核验后删除，避免留下公开 phpinfo 页面。容器环境同时核对运行实例的镜像摘要，而不是只看仓库标签已更新。
验收记录至少包含域名或业务名、运行模式、包/镜像标识、切换时间、回归结果和负责人。这样在第二天发现另一台旧节点时，可以直接定位遗漏范围。
五、WAF 与日志分别能证明什么
WAF、入口限流及上传约束可作为纵深防御，但不能替代 PHP 修复。也不要为追求“临时安全”盲目照搬内存、超时或进程回收参数；这些选项会影响资源占用和业务行为，需要结合两项公告及实际部署验证。
排查时将代理访问日志、PHP 错误、进程异常退出和文件变更放到同一时间线上。一次 500、一次内存耗尽或一条扫描记录，都不足以独立证明成功入侵；反过来，没有错误日志也不能证明安全。发现异常进程、未经授权的持久化文件或凭据访问后，应转入事件响应，保留证据并评估凭据轮换，而不是只升级后删除日志。
六、给网站管理员的处理顺序
先列清所有对外 PHP 入口和实际运行时；再依据官方或发行版公告确认修复包；接着分批切换并验证核心业务；最后核对所有工作进程和备用节点，保存验收证据。无法立即升级的站点，应明确临时防护范围、负责人和完成期限，不把临时措施登记为永久修复。
这次事件值得形成的长期改进，是把“版本清单”变成“业务到运行时的映射”。下一次基础运行时出现严重漏洞时，团队才能直接回答哪些域名受影响、谁负责升级、哪些实例已经验证，而不是重复人工猜测。
参考资料与阅读边界
文中漏洞事实以对应官方公告为依据；处置优先级、排查顺序和验收清单为 RootGS 运维分析。CVSS 是技术严重程度评分，不代表每台服务器都已遭攻击。
