PHP紧急修复两个RCE漏洞：补丁发布前已有攻击尝试

PHP 在 10 月 21 日发布紧急更新，修掉了两个高危漏洞，它们都可能让攻击者在未通过身份验证的情况下远程执行代码。亚马逊方面表示，补丁上线前的四天里，已经有人尝试利用这些漏洞。

这次修复覆盖 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 四个版本，对应的是 CVE-2026-109618 与 CVE-2026-109619。两个漏洞在 CVSS v4.0 中评分均为 9.2，还被起了个非正式名字 php2shell。它们都属于请求生命周期里的内存安全问题：一个出在内存不足的处理上，另一个出在状态超出其内存时限的环节。Sansec 称，自 PHP 5.4 起，所有没打补丁的版本都受影响。公告把可选做法写得很直接——没有完整的缓解手段，升级是唯一安全的选择。

漏洞能不能被利用，跟 PHP 的部署方式有关，官方安全公告对已验证的攻击场景措辞相当谨慎。Apache mod_php 下两种漏洞都确认存在，且都通过“针对 mod_php（使用默认 PHP 输入和内存限制）的 HTTP 攻击”得到了验证。PHP-FPM 这边，会话生命周期漏洞已被验证，至于内存不足漏洞，公告的说法是“目前尚未证明针对该 SAPI 的完整 FPM 利用方式”。FrankenPHP 仅凭源代码分析，被列为可能存在漏洞。

攻击者的动作比补丁更早。Amazon Threat Intelligence 在 MadPot 遥测数据里发现了一次利用尝试，时间可追溯到 10 月 17 日。该尝试来自“一个与商业匿名网络相关的 IP 地址”，他们建议客户“至少从 10 月 17 日开始”排查。Cloudflare 则在 10 月 21 日 UTC 时间 03:02 部署了 WAF 规则，比补丁发布早了大约 9 小时。

这套协调披露机制其实早就失灵了。PHP 基金会在声明里说，CVE 标识符比预定时间提前两天就开始流传，一名研究人员“误将一段展示概念验证的视频发布了出去”，另外“ Chainguard 单方面打破了保密协议，发布了包含修复程序的构建镜像”。基金会的原话是，后果在于“任何攻击者现在都可以研究二进制形式的修复方案，而其他所有 PHP 用户仍在等待正式发布”。Chainguard 公开的政策（最后更新于事件发生前一个月）允许它在“发现漏洞正在被积极利用”时缩短披露时间。

也有运维方宁可先停服务，不愿干等。在 r/selfhosted 版块，网友 iamShorteh 讲了自己关站的过程：

他提到，自己已经把全部网站关停（Apache2 也停了），原因是几小时前推特上有人公开了一份分步操作说明，讲的是怎么实现远程代码执行（RCE）。他不想再赌上 5-6 小时去等热补丁，所以干脆先停掉。

荷兰国家网络安全中心把网站下线作为预防措施，荷兰众议院同样如此。Sansec 则告诉商家，没必要这么做。

不少人最关心的是先确认 PHP 到底有没有在跑。有评论者发现 OPNsense、OpenMediaVault、Nextcloud 和 Coolify 背后跑的都是 PHP，评论者 spartacle 则点出了这件事为什么不好确认：

他的原话是：“对于相当一部分家庭实验室设备来说，这确实很糟糕，但有许多系统我不知道使用的是什么编程语言，容器技术让我无法看清这一点。”

接下来就是等软件包。Debian Trixie 出得很快，Ubuntu、Red Hat 和官方 Docker 镜像随后跟上。评论者 Takeoded 提到，漏洞披露十三分钟后，Ubuntu 安全团队仍未发布任何补丁。r/PHP 版块里，维护者 Ondřej Surý 收到的感谢最多，他的 Launchpad PPA 被流量压垮，运维人员只好把用户引到 packages.sury.org——该 PPA 目前正被合并进这个站点。有一支团队干脆放弃 Docker Hub，按合并后的 Dockerfile 自己构建镜像，只用了八分钟就完成。

补丁打没打上，本身又成了新的坑。评论者 SirRobinBlibs 列了几种让人白费工夫的情况：

发行版构建走的是回溯移植。Ubuntu 24.04 的修复包版本号是 8.3.6-0ubuntu0.24.04.13，可仍然显示为 8.3.6。核对完整包版本要看所用发行版的追踪器，别用 php -v 命令。命令行界面（CLI）不是 Web 服务器，不重启的话，FPM/Apache 工作进程还会把旧引擎留在内存里。

Ubuntu 的安全公告印证了这些版本字符串。两份 PHP 安全公告都建议运维人员在更新后重启所有工作进程。

漏洞的实际危害有多大，眼下还有争议。两个 CVE 都标了 AC:H 和 AT:P，意思是攻击复杂度高，且存在额外的攻击要求；Sansec 也修正了此前对漏洞被大规模利用的预期：

他们表示，已公开的漏洞利用代码对采用默认配置的 PHP 安装无效。

安全从业者看到的也是同一回事。SirRobinBlibs 提醒别拿 GitHub 上的概念验证（PoC）去测试，因为“大多数被点赞的 PoC 在原生 PHP 上无法运行，而且要小心，恶意 PoC 仓库是存在的”。JFrog 记录了一些被当作恶作剧传播的假 PoC，其中一个会改掉受害者的桌面壁纸。

r/PHP 版块有评论者问，做这项工作的人到底有多少。PHP 基金会在帖子下面回应说，PHP 的安全工作“仍然依赖于一小群由基金会资助的开发者”，并且“目前这群人数量太少”。

这条关于升级断层的留言，成了帖子里点赞最多的评论。留言认为 PHP 的终止支持政策相当苛刻：8.1 及更早版本已不在项目支持范围内，项目组只给 7.4、8.0 和 8.1 打过最基础的回溯补丁，Ubuntu 则借助 ESM 支持，把修复程序一路发到了 14.04。8.2 的支持则会在 2026 年 12 月 31 日结束。

还有第三个问题：CVE-2026-115560 眼下尚未修复。PHP 基金会的建议是，在下一个 Bug 修复版本发布前，先把 session.upload_progress.enabled 设为 0；等新版本出来后，他们会发布完整的安全公告。