PHP2Shell 的修复补丁已经发布，但对大多数需要安装补丁的网站来说，并没有一个按钮可以按下。这些漏洞存在于 PHP 本身——驱动每个 WordPress、Joomla 和 Drupal 页面运行的引擎中，位置比 CMS、插件和登录界面更底层。更新 WordPress 对它们毫无作用。修复后的解释器必须由服务器的运营方提供：可能是托管服务商、Linux 发行版的软件包，也可能是容器镜像。在补丁到位之前，无论网站所有者做什么，网站都只能继续等待。

这正是那些呼吁“立即打补丁”的标题略过的部分。PHP 团队已经完成了自己的工作，但要让补丁进入某一台服务器，取决于一条按最慢环节速度运转的交付链；发布首日，各环节之间的差距已经显露无遗。如果网站所有者不知道自己的 PHP 来自哪里，就无法判断网站仍面临多大风险。

为什么更新 WordPress 并不能修复漏洞

由于这些漏洞位于解释器中，PHP 的安全公告将所有处理网页请求的安装都列入影响范围，从 PHP-FPM、Apache 的 mod_php，到 php-cgi、FrankenPHP 和 LiteSpeed，无一例外。The Hacker News 指出，即使只是运行在易受攻击版本上的一个简单“Hello World”页面，也可能遭到攻击。最糟糕的情况出现在 mod_php：没有账户的攻击者只需发出一个请求，就能在任何应用程序代码运行之前触发攻击，因此安全插件和登录界面都无从察觉。

据 The Verge 报道，WordPress 安全服务商 Wordfence 告诉网站所有者，这项修复无法通过自动更新推送，他们需要查明究竟由谁负责维护 PHP。Laravel Forge 也向自己的客户说明了服务器上的同一情况：其自动安全更新不会修补 PHP，而 Ubuntu 的无人值守升级只会从 Ubuntu 自己的软件仓库获取更新，不会更新 Forge 安装 PHP 时使用的第三方软件包。

这些软件包来源并没有同步更新。补丁发布当天，网站管理服务 mySites.guru 报告称，cPanel 的 EasyApache 4 在安全公告发布后几分钟内就推出了修复版本，而 Ondřej Surý 的 PPA——Laravel Forge 自己依赖的 Ubuntu 软件包来源——以及 Remi 的软件仓库当时都还没有提供修复版本。InMotion Hosting 表示，其共享主机和 WordPress 服务器仍在等待 CloudLinux 的构建版本。在 mySites.guru 监测的在线网站中，截至 13:52 UTC，报告使用已修复 PHP 版本的网站占 0.08%。

版本号可能会让你误判

检查修复情况并不像看一眼版本号那么简单。Ubuntu、Debian 和 Red Hat 会回移安全修复，而不改变上游版本号，因此已打补丁的 Ubuntu 24.04 服务器仍会显示使用 8.3.6 软件包。The Hacker News 援引 Debian 的说法提醒用户，应在软件包变更日志中查找 CVE 编号，而不能只相信版本字符串。mySites.guru 还指出另一个容易踩中的陷阱：在命令行运行 php -v 所显示的 PHP 二进制文件，往往并不是实际负责提供网页服务的那个，因此应检查网站本身报告的版本。

接下来还得让补丁真正加载。PHP 的安全公告和 Forge 都强调，必须重启 Apache、PHP-FPM 以及所有长期运行的工作进程。队列工作进程和类似的后台进程会继续使用旧版解释器，除非将它们重启；无论磁盘上的文件是否已经打上补丁，都是如此。

哪些用户得不到官方修复

已修复版本包括 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，修复的漏洞为 CVE-2026-109618 和 CVE-2026-109619，两者在 CVSS v4.0 中的评分均为 9.2。对于 PHP 8.1 及更早版本，PHP 项目不会提供正式修复，只会为 7.4、8.0 和 8.1 提供最低限度的源码回移补丁，供自行编译 PHP 的用户使用。一些服务商会填补这一空缺：InMotion 表示，cPanel 已为其 7.4 至 8.1 软件包回移修复，CloudLinux 也正在为其提供的所有版本打补丁；但 CentOS 7 完全没有修复。

仍在使用旧版本的用户并不少。补丁发布前一天，mySites.guru 监测的在线 Joomla 和 WordPress 网站中，有 22.7% 运行 PHP 8.1 或更早版本，16.6% 仍在使用 PHP 7 或更早版本。该公司认为，部分原因在于 WordPress 本身：它虽然推荐使用 PHP 8.3，却仍将早已停止维护的 7.4 列为兼容版本。PHP 8.2 得到了这次补丁，但其安全支持将在 2026 年 12 月 31 日结束。

临时设置能挡住什么

补丁发布前流传的变通办法——将 session.upload_progress.enabled=0 设为关闭——确实有效，但作用有限。PHP 表示，这项设置可以阻断已确认的、通过 session 利用 CVE-2026-109619 的途径，但无法防住其他变体；必须在 php.ini、服务器配置或进程池配置中进行设置，然后重启所有工作进程。对于 PHP 8.5，设置 fatal_error_backtraces=0 还能再封堵一条已确认的攻击途径。但这两项设置都无法处理 CVE-2026-109618。针对该漏洞，PHP 建议设置不可覆盖的 memory_limit=-1、较低的 post_max_size，并在 Web 服务器或代理层限制请求大小。PHP 自己的说法是，目前没有能够彻底缓解风险的办法。InMotion 指出，WordPress、Joomla、Drupal、Magento 和 PrestaShop 都不使用上传进度功能，因此关闭它不会影响这些平台。

Cloudflare 已为所有套餐启用防火墙规则，其首席技术官戴恩·克内希特（Dane Knecht）称此举只是权宜之计。正如 mySites.guru 所指出的，只有在防火墙后方的服务器会拒绝绕过 Cloudflare、直接访问其 IP 地址的流量时，这些规则才有用。

目前的攻击情况

watchTowr 表示，其蜜罐在补丁发布当天记录到针对两个漏洞的利用尝试；Cloudflare 也发现攻击者正在更改攻击载荷，以绕过其规则。目前还没有来源证实某台具体服务器已被成功入侵。一些运营方选择不冒险：The Hacker News 报道称，BambooHR 暂停了服务，荷兰的 DigiD 等公共服务也出于预防目的暂时下线。欧盟的 CERT 和英国国家网络安全中心告知无法打补丁的机构，应隔离暴露在外的应用程序，或将其下线。

这些漏洞由 Wiz Research、Calif 和 OpenAI 的 Codex Security 团队发现。根据 PHP Foundation 的说法，内存漏洞的迹象在 2024 年的一次审计中已经浮现，但修复工作停滞了数月；该基金会称这是“一次结构性失灵”。研究人员表示，AI 模型帮助他们在大约一周内将这些存在了十年的漏洞转化为可用的攻击手段。

PHP 经历了审计、数月僵局和一次泄露，才终于推出这项修复。对于使用共享主机的网站来说，最后一步就是提交一张支持工单。

标签: Cloudflare, PHP, PHP2Shell, WordPress, 安全漏洞