要修复这两个cve，得先确认两个漏洞都被补丁完整覆盖，再逐一核对软件包、配置项和运行中的进程。上游官方版本和各发行版的回补补丁核对方法不一样，整个修复流程必须留存完整的操作证据。
先把两个修复项放进同一张变更单
处理安全预警的时候，千万别把两个CVE编号拆分给不同人跟进，最后两边进度脱节。要在变更单里记清楚业务系统信息、操作系统版本、PHP的安装来源、当前服务运行模式、用到的修复包版本和对应负责人。验收环节要同时勾选两个CVE，还要附上供应商给出的补丁覆盖说明。
官方正式维护的版本分支里，两个漏洞的首个修复版本分别是8.2.35、8.3.36、8.4.27和8.5.12。安装同一分支后续发布的安全更新，按理说都会包含这次的修复，但还是得核对更新源和官方发布说明，别不小心装到候选测试版或者被第三方篡改过的安装包。
立即学习“PHP免费学习笔记（深入）”；
两个补丁分别修复什么
第一个漏洞出在内存不足跳出当前处理上下文的场景里，后续清理阶段可能会访问到还没完成初始化的数据。第二个漏洞的成因是旧请求结束后，工作进程还留存着已经释放内存的引用，后续新请求可能还没走完正常的重置流程就用到这块内存。两个补丁覆盖的代码生命周期完全不一样，光靠改配置关掉某条路径，没法替代完整的补丁集合。
| 编号 | 核对重点 | 不应当作完成证据 |
|---|---|---|
| CVE-2026-109618 | 内存不足处理修复已包含 | 仅调大内存上限 |
| CVE-2026-109619 | 完整请求状态重置补丁 | 仅关闭上传进度 |
系统包部署：按完整包号完成核对
先拉取本地软件包清单，别上来就直接覆盖安装。先确认当前启用的软件仓库属于对应发行版的官方源，安全更新通道可用，再去查官方公告里列明的修复包版本号。
先跑模拟更新流程，检查这次更新会改动哪些CLI、FPM、Apache模块和关联扩展。如果出现关键扩展被意外移除的情况，先解决依赖冲突或者安排业务迁移，不能直接忽略变更清单就往下走。
装完更新之后，要针对实际用的服务模式做配置有效性测试，再重启服务。之后分别在网页入口和后台任务场景里验收版本号，记录服务启动时间和关键功能的测试结果。
# Ubuntu/Debian 包部署的只读盘点 dpkg-query -W 'php*' apt-cache policy php8.3-fpm php8.3-cli # Ubuntu 示例：更新前先模拟并人工核对 sudo apt update apt-get -s upgrade sudo apt upgrade
上面示例里的8.3只是服务名演示，实际操作的时候要替换成你本机当前的PHP分支。发行版打包的PHP版本号可能还是显示较早的基础版本，要看供应商的修订号才能确认有没有打上回补补丁，别直接把上游官方的小版本对比逻辑套到所有发行版的系统包上。
源码与托管环境：核对责任边界
自己源码编译安装PHP的，要去官方站点下载正式的修复包，先校验文件校验值确认没被篡改，提前保存好原来的编译参数和扩展清单，在单独的目录里构建测试没问题之后，再切到生产环境用。要是直接替换执行文件却没处理不兼容的扩展，很容易出现启动失败或者线上请求异常的问题。
用云服务商托管PHP环境的，直接找服务商要补丁覆盖的证明。让对方确认你当前站点绑定的实际PHP解释器版本、两个CVE是不是都已经修复，所有工作进程什么时候能全部替换完成。只看到套餐页面标了“安全PHP”，不能证明你的站点实例已经完成更新。
用小脚本生成核对记录骨架
<?php
// 输出双 CVE 核对记录，不把版本检查当成利用验证。
$record = ['checked_runtime'=>PHP_VERSION, 'checked_sapi'=>PHP_SAPI,
'cves'=>['CVE-2026-109618','CVE-2026-109619'],
'upstream_fixed'=>['8.2.35','8.3.36','8.4.27','8.5.12'],
'vendor_package'=>'must be recorded by operator',
'service_restarted'=>'must be verified on target host'];
echo json_encode($record,JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
把这段代码存为cve-record.php后运行就行。脚本里留的两个待核实字段会一直显示提示，不会自动填成已完成，提醒操作人员不能直接跳过现场核验步骤。本地PHP 8.5.10 WebAssembly的执行结果就是下面这样，生产包安装与服务重启需在目标环境实际验收才算数。
验收时重点排查四个错误
- 只覆盖一个编号：回到供应商公告，确认补丁集合完整再继续。
- CLI 更新、FPM 没更新：核对站点套接字、服务路径与多版本安装情况，排查漏更新问题。
- 新进程启动失败：检查配置测试结果、扩展加载错误和日志里的第一条异常信息定位根因。
- 有入侵迹象却只打补丁：先留存现场证据安排入侵调查，必要时重建系统和轮换所有凭据。
最终的修复报告至少要留存安装前后包号、实际服务名、进程替换时间和业务验证结果。多台服务器不能共用一条“已处理”记录，每个节点和独立运行环境都要单独留痕。
暂时没能安装补丁的节点，要记录清楚临时隔离方式、责任人和下一次复查时间，不能拿“等待供应商出包”当无限期拖延的理由。公网入口是否需要暂停服务，得由业务方和安全负责人及时评估后做出决定。
