这两个漏洞值得认真排查。如果你的服务器运行 PHP 网站，尤其是 WordPress、子比主题、PHP-FPM 或宝塔面板管理的 PHP 站点，需要优先确认 PHP 运行时是否已经修复。

根据 PHP 官方于 2026 年 10 月 21 日发布的安全信息，这两个漏洞的 CVSS 4.0 评分均为 9.2/10，属于严重级别。它们都可能导致远程代码执行（RCE），但根因不同：一个涉及内存耗尽后的异常处理，另一个涉及已释放内存对应的旧状态被再次使用。

先说最关键的一点：这不是 WordPress 某个插件写错了 PHP 代码，而是 PHP 解释器底层的内存管理和请求生命周期处理出了问题。 即使网站本身没有明显的代码漏洞，也可能受到影响。

一、两个漏洞的区别

依据：PHP 官方安全公告及 Google Cloud 的技术说明。

两者的共同危险在于：攻击者可能不需要登录网站，也不需要先利用 WordPress 的后台权限。 恶意请求可以在 PHP 执行网站业务代码之前，触发解释器自身的处理路径。

二、攻击者究竟是怎么利用它的？

理解这两个漏洞，关键是区分三个阶段：构造请求、触发 PHP 内部错误、把内存错误转化为代码执行。

普通网站请求通常经过以下流程：

这条链路中，前四步并不意味着每次触发都会成功执行命令。真正的 RCE 通常还需要满足特定的内存状态、执行路径等条件。不过，安全研究人员已经报告了可复现的利用结果，不能把它仅当作理论上的崩溃漏洞。

1. CVE-2026-109618：为什么内存不足可能变成远程代码执行？

这个漏洞的核心是 OOM（Out Of Memory，内存耗尽）处理不完整。

PHP 在解析请求时，会不断申请内存来保存字符串、数组、上传文件信息以及其他内部数据。正常情况下，如果内存申请失败，程序应该安全退出当前操作，保证已经初始化的数据能够被正确清理。

问题出在异常处理流程。

1. 先建立内部数据。 PHP 已经开始处理请求，部分内部结构完成了初始化，但其他结构可能还没准备好。
2. 内存申请失败。 恶意请求可以在特定条件下触发内存不足。PHP 内部可能通过 longjmp() 一类的非局部跳转机制中断当前操作。
3. 正常初始化流程被跳过。 部分变量或结构没有进入预期状态，但程序已经转入错误处理或请求清理阶段。
4. 清理逻辑使用了无效状态。 清理代码把未初始化或不完整的数据当成有效数据使用，进而引发内存破坏。
5. 内存破坏可能演变为代码执行。 如果攻击者能够进一步影响关键数据或控制执行路径，就可能从内存错误升级到 RCE。

PHP 官方公告明确描述了这一根因；Datadog 的安全研究还报告了使用未认证 HTTP POST 请求，在 PHP 8.5.11 上复现该漏洞的结果。

这里有一个特别重要的区别：

• 普通内存耗尽： 网站可能报错、请求失败或进程崩溃。
• 可利用的内存破坏： 攻击者进一步利用异常状态，可能使程序执行非预期操作。
• 成功的 RCE： 攻击者最终让 PHP 进程执行了其控制的代码。

因此，不能简单地认为“把内存打满就能拿下服务器”。难点是把内存分配失败与 PHP 内部对象、指针及执行流程联系起来。

2. CVE-2026-109619：为什么释放后的内存还会被使用？

这个漏洞属于经典的 Use-After-Free（UAF，释放后使用）。

先看一个简化的 C 语言示意：

char *ptr = malloc(100);

/* 假设这里写入了数据 */

free(ptr);          // 释放内存
/* ptr 没有被清空 */

use_data(ptr);      // 错误：继续使用已释放的内存

这段代码只是用于解释 UAF 的概念，并不是 PHP 漏洞的利用代码。

调用 free(ptr) 后，内存已经可以被分配器重新分配给其他用途，但变量 ptr 本身可能仍保存原来的地址。此时再使用它，就可能读取或操作不属于原对象的数据。

PHP 这次漏洞的特殊之处，在于它涉及跨 HTTP 请求的内部状态残留。

跨请求状态残留示意

机制依据：PHP 官方对 CVE-2026-109619 的安全公告。

官方公告指出，这种问题可能由致命错误打断状态重置流程，也可能由后续的警告或诊断信息重新写入已经清理过的错误状态而产生。攻击链涉及一个产生旧状态的操作，以及后续消费该状态的操作；它们可以发生在同一工作进程处理的不同 HTTP 请求中。

这也解释了为什么单独看一个 PHP 请求，可能找不到完整问题：触发旧状态的请求和利用旧状态的请求，不一定是同一个。

三、为什么这次漏洞对普通 PHP 网站影响这么大？

主要有四个原因。

特征	对网站安全的实际影响
PHP 运行时漏洞	不是只修复某个插件就能解决
可能无需身份认证	不能只依赖登录验证、后台权限控制
发生在业务代码执行之前	WordPress 权限校验、主题代码和插件逻辑可能来不及发挥作用
可能涉及跨请求状态	单独检查某一个请求，未必能发现完整的利用过程

PHP 官方明确指出，风险涉及 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed 等运行环境，并特别提示 Apache mod_php 的风险较高。

对 WordPress、子比主题和宝塔环境意味着什么？

如果你的网站使用 WordPress、Zibll 子比主题，或者安装了大量 PHP 插件，那么需要特别注意：

• 主题和插件不是唯一风险点。 即使 PHP 页面只输出简单内容，也可能进入存在漏洞的请求处理路径。
• WAF 不能替代 PHP 补丁。 它可以帮助限制异常请求，但很难可靠地修复解释器内部的内存管理缺陷。
• 关闭网站注册、限制后台登录也不够。 这些措施并不能覆盖所有未认证的请求入口。
• PHP-FPM 的重启有助于清除工作进程中的旧状态，但不能修复漏洞。 重启后，未修复的 PHP 仍可能再次受到攻击。

这些判断与安全研究人员对漏洞触发位置和 PHP 官方对运行环境的说明一致。

四、哪些 PHP 版本受影响？应该升级到哪个版本？

截至 2026 年 10 月 22 日，PHP 官方已经发布修复版本。

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	升级至该版本或更新的安全版本
PHP 8.1 及更早版本	需要核实发行方补丁	优先迁移到受支持的 PHP 分支

注意：旧版本并不代表完全没有修复途径。PHP 官方针对部分已经停止维护的分支也提供了有限的补丁回移；如果使用 Linux 发行版或第三方维护的 PHP 包，需要核实具体的软件包修订版本，而不是只看 PHP 的主版本号。

五、如果暂时不能升级，应该如何降低风险？

我的建议是按照以下优先级处理。

1. 第一优先级：升级 PHP 运行时。这是唯一可以从根本上修复这两个漏洞的方案。升级前先确认 WordPress、主题、插件和扩展的兼容性，并做好数据库及网站文件备份。
2. 第二优先级：限制异常请求。在 Web 服务器或反向代理层限制请求体大小、表单字段数量、multipart 分段数量及嵌套深度。对于 CVE-2026-109618，PHP 官方还建议在适当的部署环境中调整 memory_limit，减少由可控内存耗尽触发的风险。但这不能防止所有底层内存分配失败。
3. 第三优先级：针对 CVE-2026-109619 关闭已确认的触发路径。PHP 官方建议将 session.upload_progress.enabled 设置为 Off，在生效于请求解析之前的 PHP 配置中完成修改，并重启所有相关工作进程。这只能阻断已确认的部分攻击路径，不能替代升级补丁。
4. 第四优先级：排查是否已经被利用。检查 Web 访问日志、PHP-FPM 日志、系统进程和近期文件变更，重点关注异常的大型表单请求、内存耗尽错误，以及 PHP 工作进程意外启动的 shell 或其他命令行程序。成功利用不一定导致 PHP 崩溃。