PHP项目在2026年10月21日发布安全公告，披露CVE-2026-109618和CVE-2026-109619，并同时推出多个稳定分支修复版本。两项问题都涉及请求处理期间的内部状态，官方将其列为可能导致未认证远程代码执行的严重漏洞。
只要PHP实例处理来自网站的请求，就应核对实际运行的版本与供应商修复状态。安装包版本、命令行版本与Web服务实际加载的运行时可能并不一致。
这次修复覆盖哪些PHP版本
PHP项目列出的修复版本是PHP 8.5.12、8.4.27、8.3.36和8.2.35。CVE-2026-109618涉及内存不足处理打断内部请求数据初始化；CVE-2026-109619涉及请求状态所依赖的内存释放后仍被后续请求使用。
不要仅凭漏洞名称判断某个框架或WordPress插件是否受影响。问题位于PHP核心运行时，优先确认Web请求究竟由哪套PHP进程处理。
旧分支应该如何判断风险
PHP项目不再向PHP 8.1及更早分支提供常规上游更新。部分Linux发行版或长期支持供应商可能回补补丁，因此系统包版本号未必直接等于上游修复版本。
使用旧分支时，应以发行版安全公告和已安装包的修复记录核对，不能只看主版本号；没有可信回补渠道的环境应规划升级到受支持分支。
服务器升级应覆盖哪些进程
官方把PHP-FPM、Apache mod_php、php-cgi、FrankenPHP和LiteSpeed等处理Web请求的部署方式列入风险范围。升级前需盘点各站点使用的运行时，更新相应软件包或容器镜像，并重启受影响的工作进程。
容器平台还要重新构建和部署镜像。更新基础镜像后，如果运行中的旧容器仍未替换，线上请求仍可能进入旧版PHP。
临时防护有哪些边界
上游公告给出部分配置缓解手段，但明确指出它们不能完整覆盖所有利用路径。WAF或流量过滤可以作为额外防线，不能等同于修复运行时。
正式修复应以安装供应商认可的补丁版本并重启相关进程为准。对无法立即升级的生产站点，应同时收紧暴露面、监控异常请求和安排维护窗口。
升级后怎样确认生效
先确认PHP软件包或镜像来源，再在实际服务进程中查看版本，检查PHP-FPM或Web服务器重启时间，并用业务请求验证页面、上传和后台任务。多台VPS及多套PHP-FPM池要逐一核对。
验收重点是所有对外处理请求的实例都已使用修复后的运行时。发现某台仍运行旧进程时，应先处理该节点，不要把单台升级成功当成整个集群已完成。
