【安全圈】PHP官方补丁来了！速升这4个版本

安全圈 · 2026-10-22 00:00 · 23 阅读

安全圈 2026-10-22 00:00 江苏

PHP发布8.5.12/8.4.27/8.3.36/8.2.35修复两个未认证RCE严重漏洞，mod_php风险最高已有演示利用，附官方缓解措施

关键词

PHP漏洞

一、60秒看完全部要点

🚨 PHP 官方发布安全公告：两个严重漏洞可导致未经认证的远程代码执行
📦 修复版本已发布：PHP 8.5.12、8.4.27、8.3.36、8.2.35，官方强烈建议立即升级
🎯 受影响范围：所有处理 Web 请求的 PHP 安装——PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed
⚠️ 风险最高的是 mod_php：官方确认存在已演示的利用程序，一个未认证请求可在应用代码运行之前触发攻击
🔧 官方同时公布了缓解措施清单，但明确表示：只有升级才是完整解决方案
📌 PHP 7.4 / 8.0 / 8.1 提供了最小化源码 backport；用 remi 源的需自行想办法

二、官方公告：补丁已到，立即升级

PHP 官方于 10 月 21 日发布安全公告《Security advisory: Critical remote code execution vulnerabilities, update now》，宣布 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 四个受支持分支同步修复两个严重漏洞——这两个漏洞允许未经认证的远程代码执行。官方强烈建议所有 PHP 用户立即升级。

谁在风险范围内（官方原文）：所有处理 Web 请求的 PHP 安装，包括 PHP-FPM、Apache 加 mod_php、php-cgi、FrankenPHP 和 LiteSpeed。官方认为 mod_php 的风险最高——存在已演示的利用程序（exploit），一个未认证的请求可以在任何应用代码运行之前触发攻击。

这句话的分量要掂清楚："在任何应用代码运行之前触发攻击"意味着漏洞触发点位于应用层逻辑之前——依赖应用层逻辑生效的防护措施（如各类安全插件、应用内防火墙）在攻击发生时可能尚未加载。不能默认"装了防护就安全"，版本升级不可替代。

三、技术分析：两个 RCE 的机制

漏洞一：CVE-2026-109618 —— 通过内存耗尽（OOM）损坏实现 RCE

官方安全公告（GHSA-w8hw-w9fx-j79w）描述：内存耗尽的处理过程，可能在 PHP 的内部请求数据只被部分初始化时将其打断。随后的请求清理流程，可能把这份无效数据当作有效数据继续使用。

漏洞二：CVE-2026-109619 —— 通过残留的全局状态实现 RCE

官方安全公告（GHSA-6wmf-4rv5-p3rp）描述：属于某个请求的内部状态，在其底层内存被释放之后仍可能存活。同一个 worker 处理的下一个请求，可能在正常初始化将其重置之前，直接使用这份残留状态。

为什么第二条尤其值得注意：这类"跨请求状态残留"漏洞意味着打补丁之前的每一次请求，都可能给后续请求留下隐患。这也解释了为什么官方的缓解措施里反复强调一个动作——升级或应用缓解配置后，必须重启每一个 worker。这不是流程仪式，而是把残留状态彻底清空的必要操作。

四、怎么升级：各版本路径

PHP 8.2 及以上：更新到 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35。源码和 Windows 二进制在 php.net 下载页：https://www.php.net/downloads.php

Linux 发行版与 LTS 用户：发行版和 LTS 厂商已提前拿到补丁，直接向厂商获取更新包即可。

PHP 8.1 及更旧版本：已不在 PHP 官方更新范围内。部分发行版和 LTS 厂商提供 backport 修复，请联系厂商确认；或借此机会升级到受支持版本。鉴于漏洞严重程度，PHP 安全团队为 PHP 7.4、8.0、8.1 提供了最小化的源码 backport，供自行编译或无 LTS 厂商支持的用户使用。

两个特别注意：①"最小化 backport"不是完整版本更新，只是修掉这两个 CVE 的最小补丁集，需要自己打补丁、自己编译；②官方在公告中明确劝退志愿者维护的 rpms.remirepo.net 仓库——该仓库当天不会有更新，强烈建议改用发行版自带包或从源码构建。仍在用 remi 源的管理员需要自行安排升级路径。

五、官方缓解措施清单（暂时升不了级的权宜之计）

官方公告明确表述：只有更新才是完整的解决方案，以下措施只能降低特定攻击路径的暴露面，不会让安装变得安全。

针对 CVE-2026-109618（OOM 损坏）：

✅ 设 memory_limit=-1，最好用应用改不动的方式（如 FPM pool 或 Apache 配置中的 php_admin_value），并检查没有其他 pool、目录或应用设置把有限数值改回去。这消除了"PHP 内存限制被触发"这个可控失败点，但底层真实的分配失败仍可能走到漏洞路径
✅ 设较低的 post_max_size：不需要文件上传的应用设 post_max_size = 8M；必须上传的设 32M；保持 upload_max_filesize 低于 post_max_size
✅ 在 Web 服务器或代理层强制限制：解码后的请求大小、输入字段数量、multipart 分段数量、header 数量、嵌套深度——这些限制必须覆盖没有可用 Content-Length 的请求
✅ 用容器或 cgroup 限制作为可用性边界，最好是只杀掉受影响的那个 worker 的策略。不要用 RLIMIT_AS 或 RLIMIT_DATA 替代——它们反而会触发那个有问题的分配失败

针对 CVE-2026-109619（残留全局状态）：

✅ 设 session.upload_progress.enabled=0，然后重启每一个 worker。配置需通过 php.ini、FPM pool 或服务器配置在请求解析之前生效——不要依赖 ini_set() 或 FPM 的 .user.ini。这能挡住已确认的 session 路径，但挡不住其他变体
✅ PHP 8.5 上设 fatal_error_backtraces=0，然后重启每一个 worker（只挡住已确认的致命错误回溯路径）
✅ 移除那些按请求生效、会在初始化之前输出诊断信息的无效或废弃设置——用 error_reporting、display_errors 或 @ 隐藏诊断信息是没有用的
✅ 修复攻击者可触发的致命错误和执行超时，包括回调、上传或导入处理、以及清理过程中的失败

官方两个安全公告（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）含有完整技术细节，建议管理员在执行缓解前通读原文。

六、安全圈点评与处置建议

在安全圈看来，这次事件有三个值得记住的点。

第一，这是教科书级的"补丁前窗口期"处置样本。漏洞细节先于补丁泄露，从"细节已泄、补丁未到"到"官方发布修复版本"的这段时间，是最危险的暴露期。官方在公告中直接承认"存在已演示的利用程序"——这句话本身就应当触发最高级别的应急响应，而不是等 POC 在网络上大范围流传后再行动。

第二，缓解措施的定位要摆正。官方把话说得很直白：缓解措施"不使安装变得安全"。它们的价值在于为无法立即升级的环境争取时间——共享主机用户、有严格变更窗口的生产环境、依赖上游镜像的存量系统。但把缓解当成"可以不升级了"是危险的误读。

第三，"重启 worker"这个细节体现了漏洞的本质。残留状态类漏洞的修复不只是换代码——旧状态必须被物理清除。这也是很多管理员升级后以为万事大吉、却依然中招的原因之一：补丁装了，但带着残留状态的旧 worker 还在跑。无论升级还是应用缓解配置，重启所有 worker 都应是处置清单里的必选项。

给管理员的处置顺序建议：

1️⃣ 立即盘点 PHP 版本分布：所有对外提供 Web 服务的服务器、容器、面板环境逐一登记版本号，重点确认 PHP-FPM / mod_php / php-cgi 等运行方式
2️⃣ 能升级的马上升级至 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35，升级后重启所有 worker
3️⃣ 暂时不能升级的立即应用缓解配置（至少做 session.upload_progress.enabled=0 + 重启 worker；有条件的按上文清单逐项落实），并明确升级时间表
4️⃣ 排查 mod_php 环境：官方认定其风险最高且有已演示利用程序，这类主机应最优先处置
5️⃣ 共享主机用户主动联系服务商：不要问"有没有升 PHP"，要问"是否已到 8.3.36 / 8.2.35 修复版本"，并要求落实缓解配置
6️⃣ 升级后观察日志：回溯近期的异常内存耗尽、worker 重启、5xx 错误记录，评估是否存在已被利用的迹象