PHP 紧急安全更新：双 9.2 分 RCE 漏洞背后的攻防与应对

10 月 21 日，PHP 官方安全团队上演了一场教科书级的紧急响应：提前 24 小时预告、全球统一时刻放出新版本，一次性修复两个被评为 CVSS v4.0 9.2 分（严重级）的远程代码执行漏洞。PHP 8.5.12、8.4.27、8.3.36、8.2.35 四个版本同时发布，官方措辞罕见地严厉——"除了升级，没有任何完整的缓解方案"。这是近两年 PHP 生态最严重的一次安全事件，无论你运行的是小型企业官网还是大型电商平台，只要服务器上跑着 PHP，这篇文章都值得你花五分钟读完。

两个 9.2 分漏洞：RCE 的两条隐蔽路径

本次修复的两个漏洞编号为 CVE-2026-109618 和 CVE-2026-109619，都属于"未授权远程代码执行"（Unauthenticated RCE）——这是漏洞分类中最危险的等级，攻击者无需任何账号密码，仅凭一个精心构造的 HTTP 请求就可能在你服务器上执行任意代码。

第一个漏洞（CVE-2026-109618）藏在一个几乎没人会怀疑的地方：内存耗尽（OOM）处理逻辑。当 PHP 在处理请求过程中触发内存限制，引擎会在内部请求数据"只初始化了一半"的状态下被中断，而后续的请求清理逻辑却把这份残缺数据当成完整有效的数据来使用，从而产生内存破坏。换句话说，攻击者只需要让你的 PHP 进程"内存爆掉"，就有机会让它拿着脏数据继续跑。

第二个漏洞（CVE-2026-109619）则更加隐蔽：请求级别的内部状态在底层内存被释放后仍然存活，同一个 Worker 进程处理的下一个请求，可能在正常初始化流程完成之前就用到这份"过期的全局状态"。这类"用后释放"（Use-After-Free）问题历来是 RCE 漏洞的重灾区，因为攻击者可以通过堆喷等技术在被释放的内存上放置恶意数据。

为什么 mod_php 部署风险最高

官方公告特别点名：所有对外提供 Web 服务的 PHP 部署形态都在受影响范围内，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。但其中风险最高的是 mod_php——安全团队已经验证了一条针对 mod_php 的完整利用链：一个未授权请求可以在任何应用代码运行之前触发攻击。

这一点值得展开解释。PHP-FPM 架构下每个 Worker 独立处理请求，进程边界相对清晰；而 mod_php 直接嵌入 Apache 进程内部，请求生命周期的管理方式不同，使上述两个漏洞的利用条件更容易被满足。"在任何应用代码运行之前触发"意味着你的框架、你的中间件、你的防火墙插件统统来不及介入——这正是这类漏洞的可怕之处，防御纵深在引擎层之下就已被击穿。

对于仍在使用 mod_php 的团队，这次事件其实也是一个迁移信号：无论从安全还是性能角度，PHP-FPM 或 FrankenPHP 都是更现代的选择。

立即行动：版本升级对照表

修复方案非常明确，对号入座升级即可：PHP 8.5 用户升级到 8.5.12，PHP 8.4 用户升级到 8.4.27，PHP 8.3 用户升级到 8.3.36，PHP 8.2 用户升级到 8.2.35。主流 Linux 发行版和 LTS 厂商已提前收到补丁，直接更新系统包管理器中的 PHP 包即可。

需要特别提醒三件事：第一，长期依赖 rpms.remirepo.net 第三方仓库的用户，该仓库此次没有同步更新，官方建议尽快切换到发行版官方包或自行编译；第二，PHP 8.1 及更早版本已不再受官方支持，官方虽然为 PHP 7.4、8.0、8.1 提供了最小化源码补丁，但这是"救急"而非"长期方案"；第三，PHP 8.2 将在 2026 年 12 月 31 日正式终止生命周期，如果还在 8.2 或更老版本上，年底前必须把升级计划提上日程——这次漏洞只是加速器，EOL 才是真正的截止线。

暂时无法升级？临时缓解措施清单

生产环境升级需要窗口期，官方也给出了针对性的临时缓解方案，虽然都注明"不能替代升级"，但能显著缩小攻击面：

针对 OOM 漏洞：将 memory_limit 设为 -1（建议通过 php_admin_value 在 FPM 池或 Apache 配置中设置，防止应用自行覆盖），移除一切可能把有限内存限制加回来的配置；大幅调低 post_max_size（无文件上传场景建议 8M，有上传需求建议 32M），并在 Web 服务器或网关层对请求体大小、字段数量、multipart 分片数、请求头数量做硬性限制。注意不要用 RLIMIT_AS 或 RLIMIT_DATA 做资源限制——它们恰恰会触发漏洞依赖的内存分配失败路径。

针对过期状态漏洞：关闭 session.upload_progress.enabled 并重启所有 Worker；PHP 8.5 用户额外设置 fatal_error_backtraces=0；同时修复所有攻击者可达的致命错误和执行超时问题。所有缓解配置都必须在请求解析之前生效——ini_set() 和 .user.ini 在这里完全无效。

一场值得研究的开源安全响应范本

回看整个事件时间线：10 月 20 日官方发布预告，给出 24 小时准备期；10 月 21 日 14:00 UTC 准时放出版本，同步披露完整技术细节、缓解措施，甚至为已 EOL 的 7.4/8.0/8.1 准备了源码级补丁；发行版厂商提前拿到补丁，用户更新无延迟。PHP 基金会同日发文介绍了他们在安全流程上的持续建设。这种"预告—同步—兜底"的三段式响应，值得每一个维护开源基础设施的团队学习。

同一周，Laravel 也火速发布了 13.29 和 12.68，修复了一个关键的 Token Guard 身份验证绕过漏洞，并于 13.38 版本继续强化数据库读取一致性。而 PHP 8.6 的 RC4 也已在 10 月 22 日按计划推出，主版本节奏没有因为安全事件而打乱。生态在压力之下依然有序运转，这或许是 PHP 诞生三十年后依然支撑着全球近七成网站最好的底气。

安全无小事，升级要趁早。今晚就检查一下你服务器上的 PHP 版本吧——如果需要升级方案咨询或生产环境改造支持，随时可以找我们聊聊。