PHP 为两个严重 PHP2Shell RCE 漏洞发布紧急补丁，利用尝试已出现

PHP 已发布紧急更新，修复语言本身中的两个严重漏洞，使无账户的攻击者可在 Web 服务器上运行代码。修复位于 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 中，PHP 团队表示只有更新才能完全保护服务器。

这两个漏洞统称为 PHP2Shell，位于 PHP 运行时而非任何应用中，因此即使网站自身代码安全，也仍会暴露。使用 Apache mod_php 的服务器风险最高，可用的利用代码会在任何应用代码运行之前触发攻击。

两个漏洞在 CVSS v4.0 评分中均为 9.2，编号为 CVE-2026-109618 和 CVE-2026-109619。PHP 于 10 月 21 日 14:00 UTC 的预定发布时间前后公布了它们，此前一天细节在计划于 10 月 22 日披露之前已泄露。

Wiz、Calif 和 OpenAI 的研究人员发现并报告了这些漏洞，其影响可追溯至 PHP 5.4 的几乎所有 PHP 版本。

谁受影响

根据 PHP 安全公告，所有处理 Web 请求的 PHP 安装都面临风险，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。

由于漏洞存在于引擎而非任何网站的代码中，即使在易受攻击的 PHP 版本上运行简单的"Hello World"页面也可能被攻击。

公告特别指出 mod_php 风险最高，并演示了一个利用：单个未经身份验证的请求会在任何应用代码运行之前触发攻击。PHP-FPM 行为不同，因为它在请求于设置早期失败时会关闭 worker。

对于两个漏洞之一，PHP 自身的分析支持 FPM 易受影响，但表示尚未展示完整的 FPM 利用；第二个漏洞已被证明可在 mod_php 和 PHP-FPM 上达到代码执行，不过 FPM 路径依赖运行中应用内的某个操作。

攻击者还可在未先获得代码执行的情况下，读取 PHP worker 进程的内存，其中可能包含属于其他请求的密码、身份验证令牌、API 密钥和证书。

研究人员在并非其控制的应用程序上演示了这种读取实时 worker 内存的能力，使其独立于运行在 PHP 之上的应用。

应安装什么

更新处理 Web 请求的 PHP 运行时，然后重启 Apache、PHP-FPM 及任何长期运行的 PHP worker。更新 WordPress 或 Laravel 等应用并不会更新其下的 PHP 运行时；后者来自服务器软件包、主机或容器镜像。

PHP 8.1 及更早版本不再从 PHP 项目获得更新，PHP 8.2 将于 2026 年 12 月 31 日生命周期终止。对于较旧分支，PHP 安全团队已发布 PHP 7.4、8.0 和 8.1 的源码回移补丁，以帮助从源码构建或等待厂商的用户。

Linux 发行版和长期支持厂商已提前收到补丁，因此发行版软件包可能在看似陈旧的版本号下携带修复；如 Debian 所建议，应检查软件包变更日志中的 CVE 编号，而非版本字符串。

如果暂时无法更新

只有更新才是完整的修复。根据公告，以下措施可减少对特定攻击路径的暴露，但并不能使服务器安全。

对于 CVE-2026-109618，将 memory_limit 设为 -1 以使应用无法覆盖它，保持 post_max_size 较低，并在 Web 服务器或代理层强制执行请求大小限制。不要使用 RLIMIT_AS 或 RLIMIT_DATA 作为替代，因为 PHP 警告它们可能触发同一条易受攻击的路径。

对于 CVE-2026-109619，设置 session.upload_progress.enabled=0 并重启每个 worker，在 PHP 8.5 上还应设置 fatal_error_backtraces=0。关闭会话上传进度可阻断已确认的会话路径，但无法阻断其他变体，且除更新外没有任何配置更改能完全缓解该漏洞。

该设置是在补丁发布前流传的变通方法，而此次发布确认它从来都不是完整的修复。会话上传进度默认开启，并可在 PHP 完成请求设置之前触及会话处理，这就是它参与 CVE-2026-109619 一条已确认攻击路径的原因，也是关闭它对 CVE-2026-109618 毫无作用的原因。

"我唯一能说的是，唯一的缓解措施就是给 PHP 打补丁/升级。遗憾的是我知道得太多了，"PHP 核心开发者 Gina Peter Banyard 在发布前回复一位认为该设置可能足够的用户时写道。

更新后，请检查内存设置。修复引入了一个新的硬性内存限制，达到该限制会终止进程并阻止关闭处理程序运行，因此请根据应用需求检查 memory_limit 和 post_max_size。

如果您已打补丁但怀疑此前曾遭入侵，研究人员建议留意异常的多部分请求后跟内存限制错误或反复出现的 HTTP 500 响应、异常巨大的 PHPSESSID 响应 cookie，以及 PHP worker 无法解释的重启。

是否正在被攻击

在补丁发布之前，Cloudflare 表示其已看到利用这些漏洞的早期尝试。"我们看到早期攻击正在出现，并随着新向量的出现更新缓解措施，"Cloudflare CTO Dane Knecht 表示，称 Cloudflare 部署的防火墙规则只是权宜之计，并敦促管理员打补丁。

尚无来源确认成功入侵。复现了 CVE-2026-109618 的 watchTowr 报告称，截至 10 月 21 日 11:26 UTC 未发现在野利用，当时两个漏洞均不在 CISA 的已知被利用漏洞目录中。

一些组织出于预防而非应对任何入侵而下线了服务。BambooHR 在美国、加拿大和爱尔兰下线了其服务，警告薪资发放将中断，并表示尚无恢复时间。

据广播公司 NOS 报道，在荷兰，MijnOverheid、DigiD、议会下院网站、国家网络安全中心和多个教育系统下线；该中心表示尚未看到该漏洞被滥用，但敦促所有人打补丁。

事件如何曝光

一次泄露使发布提前。据 The Hacker News 报道，10 月 20 日，Hacker News 上的一篇帖子称两个 PHP 远程代码执行漏洞（附有两个 CVE 编号）将于 10 月 22 日披露，依据仅是一条可信的线报。

PHP 当晚发布了预先通知，并将发布提前至 10 月 21 日。泄露所称的 CVSS 10.0 评分并非 PHP 的评定；PHP 将两个漏洞均评为 9.2。

这些漏洞由 Wiz Research、Calif 和 OpenAI 的 Codex Security 团队发现，并与 PHP 安全团队及 Google 的 Gemini 团队合作修复。底层代码已在 PHP 中存在十多年。

研究人员表示，AI 模型帮助将这些长期存在的漏洞转化为可用的利用代码，使一名研究员在大约一周内完成了他们所称原本需要团队数月才能完成的工作。

Calif 将该漏洞的谱系追溯至 2004 年的 PHP 研究，其表示了解目标的历史仍然很重要，当前模型无法可靠地自行从晦涩的、二十年前的原始原语出发。

更新：watchTowr 报告利用尝试，仍无确认入侵

当天早些时候报告未发现任何情况的 watchTowr 在 10 月 21 日 14:19 UTC 的新公告中表示，其正观察到针对 CVE-2026-109618 和 CVE-2026-109619 的"活跃利用尝试"。Cloudflare 表示其看到针对其客户的攻击流量，并观察到攻击者更改载荷以绕过其防火墙规则，该规则已在补丁前的 03:02 UTC 默认开启。截至本次更新，尚无来源报告特定服务器被确认入侵。

PHP 基金会表示，协调披露在发布前就已瓦解。10 月 20 日约 20:00 UTC，研究公司 Calif 误发了其可用概念验证的视频；10 月 21 日 07:41 UTC，即修复发布前约六小时，厂商 Chainguard 发布了包含补丁的构建镜像，使任何人都能在其他用户等待更新时研究该修复。

更新：PHP 基金会称 2024 年审计发现了该漏洞的首个迹象

在同一篇帖子中，PHP 基金会表示，一名核心开发者在 PHP 2024 年外部审计期间首次发现了 CVE-2026-109618 背后内存耗尽漏洞的迹象，但当时仅推测出可用的攻击，并未找到具体的代码执行路径。

相互竞争的修复方案各自都有破坏兼容性、开启拒绝服务路径或强制第三方扩展更改的风险，而一个小团队难以达成一致，因此修复工作停滞了数月。基金会称这一延迟是其决策流程和资源的"结构性失败"。

Calif、OpenAI 和 Wiz 于 2026 年使用 AI 工具提交的报告确立了可用的利用代码，使该漏洞的完整影响变得清晰，并将修复推至队列首位。基金会表示，此后已改变其安全决策方式，并增加了人员和工具以更早发现类似问题。