PHP2Shell（CVE-2026-109618 和 CVE-2026-109619）：运行 PHP 的公司现在应该做什么

一名技术人员拿着笔记本电脑，在服务器机柜旁工作

2026 年 10 月 21 日，PHP 项目发布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，修复两个“可能导致未经身份验证的远程代码执行”的漏洞。说白了：任何能向您的网站发送 HTTP 请求的人，都可能在您的服务器上运行他们自己的代码。他们不需要密码，而且在某些配置下，您的应用还没执行一行代码，攻击就已经得手。这两个漏洞被统称为 PHP2Shell，PHP 给两者的评分都是 9.2（CVSS 4.0，满分 10 分）。

本指南写给需要据此采取行动的人：PHP 网站和网店的所有者、IT 经理，以及请供应商替自己运行 PHP 的所有人。本文写于 2026 年 10 月 22 日，即修复版本发布的第二天，依据的是 PHP 项目自己的安全公告、各国网络安全机构的指导意见，以及厂商公布的数据。各方说法不一致的地方，我们会指出来。

要点速览

更新 PHP 本身，然后重启它。更新 WordPress、Drupal、Laravel 或某个插件解决不了这个问题。漏洞在 PHP 里，位于您的应用之下。
据 PHP 称，所有处理 Web 请求的 PHP 安装都在影响范围内：PHP-FPM、使用 mod_php 的 Apache、php-cgi、FrankenPHP 和 LiteSpeed。PHP 认为使用 mod_php 的 Apache 风险最高。
近一半的 PHP 网站运行在 PHP 项目已不再发布版本的分支上（这是我们对 W3Techs 数据的解读，见下文）。对这些网站来说，没有可以安装的官方软件包。
配置和防火墙能争取时间，但换不来安全。PHP 列出了临时缓解措施，并表示它们“并不能使安装变得安全”。
如果您今天无法打补丁，美国、英国和欧盟的机构给出的建议是一样的：在能打补丁之前，把系统从互联网上撤下来。

事情的经过

2026 年 8 月 19 日。据 Wiz 披露的信息，其研究人员在这一天发现了第一个漏洞，并于 8 月 24 日将这些漏洞报告给 PHP 安全团队。PHP 的安全公告中也致谢了另外几家公司的研究人员。
10 月 20 日。CVE 编号在计划披露日的两天前被泄露到网上。PHP 将发布提前一天，改为 10 月 21 日 14:00 UTC，并通知所有人做好准备。
10 月 21 日 03:02 UTC。Cloudflare 为所有使用其 WAF 的客户启用了防火墙规则，免费套餐也包括在内。它后来报告称“观察到针对我们客户的攻击流量”，并看到攻击者“变换攻击载荷，试图绕过我们的防护”。
10 月 21 日 14:00 UTC 前后。PHP 发布修复版本和安全公告。同一天，美国 CISA、英国 NCSC、CERT-EU，以及由欧盟委员会、ENISA、CERT-EU、Europol 和欧盟各国 CSIRT 共同发表的联合声明，都要求各组织立即打补丁。

有多严重？

这次与每月例行的补丁有三点不同。

攻击者只需要一个请求。不需要登录，也不需要有人点击链接。PHP 的安全公告描述了一个已演示成功的、针对使用 mod_php 的 Apache 的漏洞利用：在这种场景下，“一个未经身份验证的请求可以在任何应用代码运行之前触发攻击”。Wiz 演示了针对当前版本 WordPress、Drupal 和 Joomla 的攻击，并指出“即使是运行在受影响 PHP 版本上的一个简单的‘Hello World’应用，也可能存在漏洞”。以这种方式运行的代码拥有 Web 服务器账户的权限，而在大多数网站上，这个账户可以读取应用的配置：数据库密码、API 密钥、邮件和支付凭证。对于第二个漏洞 CVE-2026-109619，PHP 还确认存在内存信息泄露：即使没有实现完整的代码执行，服务器内存中的数据也会泄露出去。

安装基数极其庞大。根据 W3Techs 的数据，在已知服务器端语言的网站中，69.3% 运行 PHP（2026 年 10 月 22 日的数据）。Palo Alto Networks 的 Unit 42 根据自己的互联网扫描，统计到超过 2260 万个可能存在漏洞的暴露实例，并报告称至少有一个欧洲国家的政府出于预防将其网站下线。

漏洞利用的进展很快。CERT-EU 报告称，最初的概念验证（PoC）“已开始流传”。安全公司 watchTowr 表示，其蜜罐自 10 月 21 日起就记录到了漏洞利用。Cloudflare 报告了攻击流量。Wiz 还说，其研究人员全程使用了 AI 模型，因此一名研究人员一周就完成了“原本需要一支世界级团队花上几个月”的工作。针对您的 PHP 版本改造漏洞利用代码的攻击者，手里也有同样的工具。

公平起见，也要说说另一面：CISA 在 10 月 21 日发布警报时，尚未观察到漏洞被利用，这两个漏洞当时也都还没有进入其 Known Exploited Vulnerabilities（已知被利用漏洞）目录。Red Hat 将该问题评为“Important”（重要）级，而不是严重级，因为标准的 Red Hat Enterprise Linux 服务器运行的是 PHP-FPM，在这种配置下利用难度更大。难度更大不等于不可能：PHP 确认，第二个漏洞的一条利用路径在 PHP-FPM 上同样有效。这些都不会改变您应该做的事，改变的只是您能提前得到多少预警。

您用的是哪个版本？看看数据

W3Techs 还公布了网站运行的 PHP 版本，统计的是公开了自身版本号的网站。把它 2026 年 10 月 22 日的两张表合在一起看：

PHP 分支	占 PHP 网站的比例	PHP 项目提供的修复
8.3、8.4、8.5	约 34%	有：8.3.36、8.4.27、8.5.12
8.2	约 18%	有：8.2.35。但 8.2 本身将于 2026 年 12 月 31 日生命周期结束
8.0、8.1	约 14%	无发布版本。8.0 和 8.1：仅有源码向后移植
7.x	26.9%	无发布版本。7.4：仅有源码向后移植；7.3 及更早版本：没有任何修复
5.x 及更早版本	7.8%	没有任何修复

也就是说，约 48% 的 PHP 网站运行在 PHP 项目不发布修复版本的分支上，另有 18% 现在能拿到修复，但十周后就会失去支持。

有两点需要注意。W3Techs 只能看到公开版本号的网站。而且，Linux 发行版可能自己给旧分支打了补丁：Ubuntu 就是这样做的，下文会讲到。仅凭版本号无法判断您是否受到保护，能说明问题的是您的厂商所提供软件包的版本。

第 1 步：找出您运行的所有 PHP

没有列入清单的东西，您就没法打补丁，而 PHP 往往藏得很深。英国 NCSC 要求各组织找出每一个 PHP 系统，先从面向互联网的系统入手，并补充说：“不要把排查范围局限于过时的 PHP 版本”。欧盟联合声明警告说，某些产品“即使看起来没有直接使用 PHP，也可能受到这些漏洞的影响”。

要查看的地方：

网站和网店：WordPress 和 WooCommerce、Drupal、Joomla、Magento 和 Adobe Commerce、Shopware、PrestaShop、TYPO3，以及任何基于 Laravel 或 Symfony 构建的系统。
被遗忘的系统：活动微站、旧的语言版本、能从互联网访问的预发布和测试服务器、有人几年前装的网页邮箱或客服工单系统。
容器：每个基于 php 基础镜像构建的镜像都带有自己的 PHP。更新宿主机对它毫无作用。
主机控制面板：cPanel、Plesk 等面板在系统自带的 PHP 之外，还附带自己构建的 PHP。面板中启用的每个版本，都要单独更新。
内置 PHP 的产品：专用设备、监控工具、CRM、客服工单系统和厂商的管理界面。荷兰 NCSC 维护着一份此类产品的公开清单，按供应商逐一列出状态。
供应商：您的托管服务商、外包公司，以及任何您知道底层是 PHP 的服务。以书面形式询问他们，您的系统运行的是哪些 PHP 版本，以及何时会打补丁。

对每一项，记下 PHP 版本、PHP 的运行方式（mod_php、PHP-FPM、LiteSpeed、FrankenPHP、容器）、是否能从互联网访问，以及谁有能力为它打补丁。

第 2 步：按正确的顺序打补丁

先处理能从互联网访问的系统，在这些系统中，又先处理 Apache mod_php 配置。

受支持的分支（8.2 到 8.5）。更新到 8.5.12、8.4.27、8.3.36 或 8.2.35，或者更新到您所用发行版中包含修复的软件包。PHP 表示，各 Linux 发行版已提前拿到了补丁。目前已确认的有：

Ubuntu：从 14.04 到 26.10 的每个版本都有修复后的软件包。在 22.04 及更高版本上，修复随常规更新提供；在 20.04 及更早版本上，需要 Ubuntu Pro 订阅，最多五台机器可免费使用（Canonical 的公告）。
Debian：Debian 13 的 php8.4 8.4.27（DSA-6574-1），以及 Debian 12 的 php8.2 8.2.35（DLA-4848-1）。
Red Hat Enterprise Linux：Red Hat 的安全通报 RHSB-2026-013 按发行版本列出了相应的软件包。
Remi 软件源（在 Red Hat 系列系统上被广泛用来安装较新的 PHP）：10 月 21 日，CERT-EU 指出它没有在发布当天提供软件包，并建议改用发行版的软件包或从源码构建。在依赖它之前，先确认它是否已经跟上。

PHP 7.4、8.0 或 8.1。PHP 项目不为这些分支发布版本。其安全团队为这三个分支做了最小化的源码向后移植（backport），如果您自己编译 PHP，这些补丁会有用。否则，修复只能来自您的厂商（例如，Ubuntu Pro 覆盖 Ubuntu 20.04 上的 PHP 7.4），或者来自升级 PHP。对于使用 8.1 或更早版本且无法更新的用户，CISA 的建议很直接：在打上补丁或完成升级之前，让系统下线。

PHP 7.3 或更早版本。PHP 项目不会提供任何修复。除非还有厂商在为您的构建版本打补丁，否则只能二选一：升级，或者让系统下线。

更新后要重启。安装软件包并不会替换已经在运行的 PHP。Ubuntu 的公告说得很明白：应用程序“很可能需要重启”。在每台服务器上重启 PHP-FPM、Apache、LiteSpeed 或容器。然后检查 Web 服务器实际运行的版本，而不只是在命令行上运行 php -v，因为命令行用的可能是另一个构建版本。

容器：用打过补丁的基础镜像重新构建您的镜像，然后重新部署。宿主机即使打了补丁，只要运行的是旧镜像，就仍然暴露在风险之下。

托管主机：向服务商问清日期和版本，然后自己核实。

第 3 步：如果您今天无法打补丁

PHP 的安全公告列出了临时缓解措施，并在介绍时先给出警告：这些措施“能减少特定攻击路径的暴露面，但并不能使安装变得安全”。简要列出如下，供负责管理您服务器的人参考：

针对 CVE-2026-109618：设置 memory_limit=-1，并确保应用无法覆盖这一设置（例如在 PHP-FPM 池或 Apache 配置中使用 php_admin_value）；把 post_max_size 设得较低（PHP 建议不需要文件上传时设为 8M，需要时设为 32M）；在 Web 服务器或代理上限制请求大小、字段数量和 multipart 分段数量；并使用容器或 cgroup 内存限制，切勿使用 RLIMIT_AS 或 RLIMIT_DATA。
针对 CVE-2026-109619：在 php.ini 或服务器配置中设置 session.upload_progress.enabled=0（不要用 ini_set() 或 .user.ini 文件），并重启所有工作进程。在 PHP 8.5 上，还要设置 fatal_error_backtraces=0。

有两点警告。正如 PHP 安全团队的一名成员所指出的，10 月 20 日广为流传的那个 session 设置只能封堵第二个漏洞的利用路径，对第一个漏洞毫无作用。另外，memory_limit=-1 会取消 PHP 自身的内存上限，于是单个繁重的请求就可能耗尽服务器的资源。请把它与容器或 cgroup 限制配合使用。

Web 应用防火墙能帮上一点忙。Cloudflare 的规则对所有带 WAF 的套餐默认开启，免费套餐也包括在内；Palo Alto Networks 等厂商也发布了各自的防护措施。但 Cloudflare 仍然要求客户“即使有 WAF 防护”也要给 PHP 打补丁，而且它亲眼看到攻击者改变攻击载荷，试图绕过它的规则。WAF 也只能保护经过它的流量。如果您的服务器通过自己的 IP 地址也能直接访问，攻击者就可以绕过 WAF。

如果这些都无法很快完成，CISA、CERT-EU、NCSC 和欧盟联合声明指向的是同一个方向：在修复之前，把系统从公共互联网上撤下来。挂一天维护页面的代价，比重建一台服务器要小。

第 4 步：检查您是否已经被入侵

风险窗口从 10 月 20 日泄露开始时就已打开，第二天早上就有了攻击流量的报告。如果某个系统在这段时间内可以访问且未打补丁，打补丁只能把门关上，却无法告诉您在此之前是否已经有人进来。NCSC 要求所有未能立即打补丁的人检查是否存在入侵迹象和后门。

需要关注的迹象，依据的是已公布的指导意见和常规的事件响应实践：

PHP 进程做了 PHP 从来不会做的事，例如启动 shell 或下载工具（CISA）。
异常的 multipart 请求，随后出现内存限制错误或反复出现 HTTP 500 响应，PHP 工作进程无明显原因地重启，以及响应中出现异常大或格式错误的 PHPSESSID cookie（Wiz）。
上传目录、缓存目录或网站根目录中出现新增或被修改的 PHP 文件，CMS 中出现新的管理员账户，以及没人创建过的计划任务。

日志干净并不能证明什么。PHP 针对第二个漏洞的安全公告正是对此提出了警告，Wiz 也指出，应用日志中可能只有很少的上下文信息。

如果发现了问题，要当作安全事件来处理，而不是当作打补丁的工作。隔离服务器，保留证据，请应急响应服务商介入，并更换 Web 服务器能读取到的每一项机密：数据库密码、API 密钥、支付和邮件凭证、签名密钥。由于第二个漏洞可能泄露内存，对于任何暴露在外且数日未打补丁的服务器，即使没有入侵迹象，也可以考虑轮换其中最敏感的那些机密。

第 5 步：您可能需要通报什么

漏洞本身并不是需要通报的事件。被利用的漏洞则可能是。

NIS2：如果您的组织在 NIS2 的适用范围内，而一次入侵构成重大事件，就必须在 24 小时内向您所在国家的 CSIRT 提交早期预警。参见我们的 NIS2 指南。
GDPR：如果个人数据被访问，必须在您知悉泄露后 72 小时内通报监管机构，除非该泄露不太可能给相关人员带来风险。参见我们的 GDPR 指南。
网络韧性法案：如果您销售内置 PHP 的软件或设备，根据网络韧性法案（CRA），您就是它的制造商。正如欧盟联合声明所提醒的，自 2026 年 9 月 11 日起，制造商必须通过网络韧性法案统一通报平台，通报其产品中被主动利用的漏洞。参见我们的网络韧性法案指南。
您的客户：如果您为客户托管或运行 PHP，他们会来问。一份简短的书面说明（您运行的是什么、何时打的补丁、检查了哪些内容）就能回答大部分问题，而审计人员或网络保险公司想看的也正是这份说明。

紧急处置之后：需要改变什么

在大多数管理良好的服务器上，PHP2Shell 会在几天内修补完毕。但它所暴露出的您环境中的问题，在那之后依然存在。

弄清楚您打一次补丁需要多长时间。从安全公告发布到所有服务器都完成重启：几小时、几天，还是几周？如果诚实的回答是“得去问外包公司”，就在下一次之前把这个问题解决掉。既然研究人员说 AI 把他们的漏洞利用工作从几个月缩短到了一周，就要假定攻击者也能以这样的速度行动。
保留您刚刚建立的清单。它是这次响应中最难的部分，而一旦没人负责，它马上就会过时。
淘汰生命周期已结束的 PHP。这一次，运行 7.4 或 8.1 的网站需要依靠厂商或源码向后移植；下一次可能两者都没有。PHP 8.2 将于 2026 年 12 月 31 日生命周期结束，所以从 8.1 迁出的网站应该直接升级到 8.3 或更高版本。迁移 PHP 往往也意味着要更新应用：我们关于 Drupal、Umbraco 和 Kentico 生命周期结束的文章，以一个 CMS 为例说明了这涉及哪些工作。
尽可能用 PHP-FPM 代替 mod_php。这一次，它是风险较低的配置。
如果用不到上传进度功能，就让它保持关闭。PHP 的安全公告建议，如果应用不需要 session.upload_progress.enabled，即使打了补丁之后也保持关闭。
把补丁时限写进合同。问清您的托管服务商和外包公司，他们多快能应用针对 PHP 严重漏洞的修复，并拿到书面答复。

本周检查清单

列出每一个 PHP 安装，包括容器、控制面板、厂商产品和预发布服务器。
先给面向互联网的系统打补丁，从 Apache mod_php 开始。
重启所有 PHP 进程，并检查 Web 服务器报告的版本。
重新构建并重新部署容器镜像。
今天无法打补丁的地方，应用 PHP 的临时配置，让流量经过 WAF，或者让系统下线。
以书面形式向供应商和托管服务商询问其 PHP 版本和打补丁日期。
对自 10 月 20 日以来暴露在外且未打补丁的所有系统，检查日志和文件变更。
判断是否适用通报义务（NIS2、GDPR、网络韧性法案）。
规划从 PHP 8.1 及更早版本迁出，并在 12 月 31 日之前从 8.2 迁出。

我们能在哪些方面提供帮助

大多数公司并不缺打补丁的意愿。它们缺的是对自己运行着什么的清晰了解，或者是本周能把活干完的人手。这正是我们承担的部分：

几天内完成盘点和打补丁。我们在服务器、容器、主机面板和供应商那里找出您的 PHP 安装，为它们打补丁、重启并验证，并给您留下一份书面记录，写明做了什么、何时做的。这份记录同时也是您给客户和审计人员的答复。
摆脱旧版 PHP。应用因为代码在更新的版本上跑不起来而卡在 PHP 7.x、8.0 或 8.1 上：我们通过遗留系统维护服务把它们移植到受支持的版本。
加固和例行补丁流程，让下一次安全公告变成一项按计划进行的工作，而不是一场紧急状况。

如果您发现了入侵迹象，请先联系应急响应服务商。我们可以与他们配合，承担重建和升级工作。

请写信到 office@c9group.dev，告诉我们您运行的是什么，我们会在回复中告诉您我们会先做什么。

来源

核查日期：2026 年 10 月 22 日。局势仍在发展：尤其是漏洞利用状态和厂商软件包，此后可能已经有了变化。

PHP 项目

机构

研究人员、厂商和数据