PHP2Shell：PHP 严重漏洞对 mod_php 服务器影响最大

在两个漏洞的细节于前一天在 Hacker News 上泄露后，PHP 将安全版本的发布时间提前至 UTC 时间 10 月 21 日星期三下午 2 点。修复随 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 一同发布。这两个漏洞都存在于解释器本身，而非 CMS 中。PHP 针对 CVE-2026-109618 和 CVE-2026-109619 的安全公告均给出了 CVSS 4.0 评分 9.2，并确认攻击者无需身份验证即可使用 Web 工作进程的权限执行远程代码。

内存耗尽处理导致内存仅完成部分初始化

第一个漏洞的根源在于 PHP 处理内存耗尽错误的方式。发生 OOM 时，解释器会使用 longjmp() 跳出当前上下文，即使此时请求内存仅完成了部分初始化。随后，关闭流程会将该状态当作有效状态读取。攻击者可以通过未超过 post_max_size 限制的 multipart 请求触发 OOM，例如为每个部分添加不限数量的头部、使用不计入 max_file_uploads 的空文件字段，或使用嵌套字段名。补丁将 longjmp() 替换为在下一个虚拟机安全点触发的软 OOM，并在超过第二个更高阈值时通过 _exit() 强制退出。

第二个漏洞涉及生命周期超出单次请求的全局状态。如果致命错误在某项操作重置状态之前将其中止，一个全局字段就会继续指向已释放的堆内存。当同一工作进程上的下一个请求在正常初始化之前读取该值时，就会发生释放后使用。PHP 列出了两条已确认的触发路径：PHP 8.5 中的 fatal_error_backtraces 设置，以及默认启用且无需应用程序调用 session_start() 的会话上传进度功能。

为什么 mod_php 面临的风险最大

使用 mod_php 的 Apache 即使在请求启动已经失败的情况下，仍会调用请求关闭流程。只需在 PHP 解析请求体时耗尽内存即可触发，无需运行任何应用程序代码。PHP 已验证，在默认内存和输入限制下，可针对 mod_php 实现完整的代码执行。PHP-FPM 会终止启动失败的子进程，从而阻断这条直接利用路径。对于第二个漏洞，PHP 仍确认可针对普通 FPM 进程池实施利用，不过这取决于应用程序中是否存在合适的操作。源代码分析表明，FrankenPHP 的行为与 mod_php 类似，而 LSAPI 在特定条件下也可能受影响。CVSS 向量中的高攻击复杂度反映了 PHP 构建方式和堆布局会影响利用的可靠性。

漏洞利用尝试与 AI 的作用

watchTowr 表示，已观察到针对这两个漏洞的活跃利用尝试，Cloudflare 也向 The Hacker News 表示，在补丁发布前就已发现早期攻击。目前尚未确认有系统被成功攻陷。包括 DigiD 和 MijnOverheid 在内的荷兰政府服务仍出于预防目的下线，英国 NCSC 则建议，在别无选择的情况下将未打补丁的系统下线。

Wiz Research 发现了这些漏洞，并于 8 月 24 日报告。Wiz 称，Gemini 4 Argon 和 GPT-5.6 Sol 协助了漏洞发现、利用程序开发和补丁验证，尤其是在针对各个目标调整利用程序方面。Wiz 还感谢 OpenAI 和 Calif 在漏洞发现及协调工作中提供的帮助。这与 Anthropic 最近关于以廉价电视盒子为目标的自我复制 AI 的文章所述情况一致：模型同样降低了攻击门槛。

管理员现在应该做什么

更新是唯一彻底的修复方法。Linux 发行版和 LTS 供应商已提前获得补丁，通常会以旧版本号回移这些补丁，因此应在更新日志中查找 CVE 编号，而不是只看版本字符串。已停止支持的 7.4、8.0 和 8.1 分支仅获得最低限度的源码补丁回移。如果无法立即更新，PHP 建议通过管理员配置设置 memory_limit=-1，因为已确认的 OOM 利用正是依赖可预测的单次请求内存限制。再设置 session.upload_progress.enabled=0，并在 PHP 8.5 上设置 fatal_error_backtraces=0，然后重启所有工作进程。如果应用程序不使用 multipart 表单，请在前端拦截此类请求。这些设置都不能彻底修复漏洞。如果使用共享主机或带有 Web 服务器的 NAS，请检查供应商提供的 PHP 版本。