针对 2026 年 10 月 21 日 PHP 官方发布的紧急安全公告（修复 CVE-2026-109618 和 CVE-2026-109619 两个 CVSS 9.2 级的漏洞），整理的漏洞详情、修复及缓解方案如下：

1. 漏洞原理与危害简述

2. 修复方法（彻底解决）

直接升级至官方已修复的 PHP 版本是唯一能消除风险的完整方案。

升级目标版本：

• PHP 8.5 分支：升级至 8.5.12

• PHP 8.4 分支：升级至 8.4.27

• PHP 8.3 分支：升级至 8.3.36

• PHP 8.2 分支：升级至 8.2.35

实操步骤：

# Ubuntu / Debian 系统示例：
sudo apt-get update
sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli php8.3-common # 根据实际使用的 PHP 分支修改版本号
# CentOS / RHEL / Rocky Linux 示例：
sudo yum update php php-fpm php-common
# 升级完成后必须重启 Web 服务与 PHP-FPM 服务：
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx # 或 apache2

注意：如果通过 Linux 官方源或 LTS 厂商安装，请确认包管理器获取到了 2026 年 10 月 21 日及以后发布的补丁包。若使用源码编译，需前往 php.net 下载对应分支最新的源码包重新编译部署。

业务影响：

• 重启短暂中断：重启 php-fpm 或 Apache 时会造成数秒的请求瞬断（建议在业务低峰期操作，或使用平滑重启 reload）。

• 兼容性影响：本次升级为小版本（Patch）安全更新，不会引入破坏性的 API 变更，对已有业务代码兼容性影响几乎为零。

waf 能拦吗

答案是：可以拦截部分攻击变种，但不能作为完全依赖的防御手段，无法做到 100% 免疫。

WAF（Web 应用防火墙）在本次安全事件中属于辅助缓解层，它的能力边界和局限性如下：

一、WAF 能拦住什么？（有效场景）

1. 特定已知特征的载荷（CVE-2026-109619）：对于利用 session.upload_progress 或已知特定反序列化/全局状态篡改的攻击 payload，若 WAF 开启了最新的签名规则库（如包含相应漏洞正则的规则），可以在网关侧直接阻断该类 HTTP 请求。

2. 超大/异常 Request 限制（CVE-2026-109618）：WAF 或入口 Nginx 可以强制限制 Content-Length、Multipart 嵌套深度、请求头数量及 Body 大小（如限制在 8M/10M 以内）。这能直接切断通过“超大 Post 请求触发 OOM”的特定攻击路径。

二、为什么 WAF 不能彻底替换补丁？（局限与绕过风险）

1. 绕过风险高（Bypass）：RCE 漏洞的 Payload 往往可以通过编码（如 Base64、URL 编码、混淆）、分块传输（Chunked）或利用不同的 Content-Type/Multipart 格式绕过 WAF 的正则检测。

2. 协议与底层解析差异：WAF 解析 HTTP 请求的 Engine 与 PHP 底层（Zend Engine / FPM）在解析极极端或异常报文时可能存在差异。如果攻击者构造了“WAF 认为是合法/无法理解、但 PHP 却能成功解析并触发 OOM/残余状态”的畸形请求，WAF 就会失灵。

3. 针对 CVE-2026-109618 (OOM) 的固有缺陷：OOM 路径的根本问题在于“PHP 内部内存不足后的清理逻辑异常”。即便攻击者发送的请求体积符合 WAF 规则，只要目标服务器当时的系统内存紧张，或者通过组合正常业务接口消耗了服务器资源，同样可能触发 OOM 路径。这种流量在 WAF 看来完全是正常的合法业务流量。