PHP2Shell漏洞安全报告：受影响版本与修复方案

简短回答：PHP2Shell 是 PHP 引擎本身两个严重漏洞（CVE-2026-109618 与 CVE-2026-109619）的统称，PHP 官方已于 2026年10月21日发布紧急修复版本。未经身份验证的攻击者只要能访问 PHP 网站服务器，就可能在其上执行代码。请升级到 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35，重启所有 PHP 工作进程，并找出你不知道自己在运行的 PHP。

PHP2Shell 漏洞是什么？一段话讲清楚

2026年10月21日，PHP 项目一次性发布四个安全版本（8.5.12、8.4.27、8.3.36 和 8.2.35），修复解释器核心请求处理逻辑中的两个远程代码执行（RCE）漏洞，业界称之为 PHP2Shell。PHP 项目对这两个漏洞的评分均为 CVSS v4.0 9.2 分（严重）。其安全公告指出，风险适用于“所有处理网页请求的 PHP 安装”，无论 PHP 是以 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 还是 LiteSpeed 方式运行。漏洞细节在原定披露日的前一天提前泄露，补丁窗口因此比平常短得多。数小时内，多家安全公司就报告了攻击尝试。到10月22日至23日，美国 CISA、英国 NCSC、新加坡网络安全局（CSA）和香港 HKCERT 均已发布警报。

本文梳理目前已知的事实、仍不确定之处，以及香港、中国内地和新加坡的 IT 或安全负责人在未来 24 小时、72 小时和 7 天内应当做什么。它面向需要拍板和落实的人，而不只是工程师。

CVE-2026-109618 和 CVE-2026-109619 具体是什么？

两个漏洞都位于 PHP 本身，处在 WordPress、Drupal、Laravel、Magento 或任何插件之下。把应用程序更新到最新版本并不能保护你，只有更新 PHP 运行时才行。

CVE-2026-109618：内存耗尽破坏导致的远程代码执行

PHP 的安全公告（GitHub 公告 GHSA-w8hw-w9fx-j79w）这样描述：内存耗尽（out-of-memory）处理可能在内部请求数据只初始化了一部分时中断 PHP，随后请求清理代码可能把这份未构建完成的数据当作有效数据处理。如果攻击者能在恰当时机让某个 PHP 工作进程陷入内存耗尽状态，就可能把这种混乱转化为对该进程的控制。Google 的响应指南提到，攻击者可能利用体积很大的请求载荷来触发内存耗尽。

CVE-2026-109619：残留全局状态导致的远程代码执行

第二份公告（GHSA-6wmf-4rv5-p3rp）描述的是：请求所属的内部状态在其内存被释放后依然留存。同一 PHP 工作进程处理的后续请求，可能在正常启动流程重置之前就用到这份残留状态。新加坡 CSA 将其归类为释放后使用（use-after-free）漏洞。由于 PHP 工作进程寿命很长、会处理大量请求，一位访客的请求就可能影响同一进程上的下一个请求。

谁面临的风险最高？

PHP 项目表示，使用 Apache 搭配 mod_php 的风险最高。针对这种环境，已有演示性的利用方式：未经身份验证的请求就能在任何应用代码运行之前触发攻击。这一点至关重要。登录页面、写在代码里的应用层防火墙、加固过的 CMS 配置，都帮不上忙，因为攻击发生在这些机制执行之前。多伦多大学的公告补充说，CVE-2026-109619 在 PHP-FPM 路径上需要配合合适的应用操作，这提高了利用难度，但并不意味着安全。

严重程度到底如何？

PHP 项目：两个漏洞均为 CVSS v4.0 9.2 分（严重）。
部分公开漏洞数据库：CVE-2026-109618 的 CVSS v3.x 评分为 9.8，CVE-2026-109619 为 8.1。
watchTowr：考虑到 PHP 部署之广、攻击者所需条件之少，将其视为 10.0 分。

评分有高有低，结论并无二致：互联网暴露的网站服务器上出现未经身份验证的远程代码执行，就应当放下手头一切工作来处理。

时间线：从发现到被实际利用

公开报道仍在不断更正，因此下面的时间线只采用至少有一份一手或可靠来源报告证实的日期。所有时间均为 UTC。

2026年8月：研究人员各自独立发现这些漏洞。公开报道称功劳归于 Calif 和 Wiz 的团队，二者都使用了 AI 辅助分析。据报道，其中一个底层的内存耗尽问题在 2024 年的一次审计中就曾被注意到，但一直没有修复。
2026年10月17日：Amazon Threat Intelligence 后来报告称，其蜜罐遥测数据中自这一天起就出现了利用尝试，比公开披露早了四天。
2026年10月20日：细节在 Hacker News 上泄露，早于原定的10月22日披露。PHP 项目宣布将于10月21日 14:00 UTC 紧急发布版本。
2026年10月21日 13:34 UTC：两份 GitHub 安全公告公开，略早于计划的发布时间。
2026年10月21日：PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 发布，并为 8.1、8.0 和 7.4 提供了最小化的源码回移补丁。新加坡 CSA 和美国 CISA 发布警报。watchTowr 报告其蜜罐网络遭到利用尝试，Cloudflare 报告出现早期攻击尝试并部署了临时 WAF 规则。
2026年10月22日：HKCERT 发布警告，敦促香港企业检查并修补 PHP 系统。CSA 更新警报。Google Cloud 更新其 WAF 与检测指南。截至当日，这两个 CVE 尚未被列入 CISA 的已知被利用漏洞（KEV）目录。
2026年10月23日：HKCERT 更新其10月22日首发的安全公告，将此事件评为极高风险，并表示这些漏洞正在被实际利用。

结论很清楚：从披露到遭受攻击，间隔现在以小时计，而不是以周计。HKCERT 也指出了同一点：AI 工具正在缩短漏洞披露、扫描和尝试利用之间的时间。

哪些 PHP 版本受影响、哪些已修复？

所有仍在维护的分支在更新之前都受影响，几乎所有更旧的版本也是如此。

PHP 8.5：8.5.12 之前受影响，8.5.12 已修复。
PHP 8.4：8.4.27 之前受影响，8.4.27 已修复。
PHP 8.3：8.3.36 之前受影响，8.3.36 已修复。
PHP 8.2：8.2.35 之前受影响，8.2.35 已修复。请注意，PHP 8.2 将于2026年12月31日终止支持（EOL）。
PHP 8.1、8.0 和 7.4：受影响，且已终止支持。官方没有发布二进制版本，PHP 项目只提供了最小化的源码回移补丁，部分 Linux 发行版和长期支持（LTS）厂商会提供已打补丁的软件包。
PHP 7.3 及更旧版本（包括 PHP 5.x）：受影响，且没有修复。唯一稳妥的做法是升级到仍受支持的分支，或把系统从互联网上下线。

有两个实际操作中的陷阱，常让团队踩坑：

厂商回移补丁会保留旧版本号。在已打补丁的发行版或控制面板构建中，`php -v` 可能仍显示旧版本。请查看厂商的更新日志或安全公告，确认其中同时列出了两个 CVE 编号，以此判断是否已修复。
并非所有软件源在第一天就完成更新。PHP 项目特别提醒第三方软件源 rpms.remirepo.net 的用户，改用发行版自带软件包或从源码编译，因为该软件源在发布当天不会有更新。

为什么这对香港、中国内地和新加坡的企业很重要？

PHP 支撑着很大一部分网站。HKCERT 引用的报告称，超过 75% 的网站使用 PHP，并估计联网的 PHP 主机约有 510 万台。但对大多数亚洲企业而言，更大的风险并非主站，而是那些他们并不知道存在的 PHP。

PHP 藏在资产清单覆盖不到的地方

HKCERT 提醒，PHP 可能内置于应用程序、网络与安全设备、存储系统和监控系统的管理界面及运维组件中。这些内嵌的 PHP 往往与操作系统的 PHP 版本不同，常规的资产盘点因此会漏掉它们。典型的排查位置包括：

虚拟主机控制面板：例如 cPanel、Plesk、HestiaCP 和 VestaCP，它们自带 PHP 构建。
老旧的内网系统及人事、预订或工单工具：多年前由本地服务商开发，从未升级到 PHP 7 以上。
网络、防火墙、VPN、NAS 和监控设备：带有基于 PHP 的网页控制台。
营销网站和电商店铺：基于 WordPress、WooCommerce、Magento 或 OpenCart，通常由第三方托管。
容器与镜像：内含 PHP，却很少重新构建。

监管机构和保险公司会来问

对受监管的企业来说，这也是一个举证问题。新加坡 CSA 建议各机构审查所有运行 PHP 的系统，优先处理面向互联网的服务器，并检查间接捆绑的组件。受香港金管局（HKMA）或证监会（SFC）监管的企业，以及须履行等保（MLPS）义务的内地业务，都应预期审计人员、客户和网络安全保险公司会问一个简单的问题：你什么时候知道的，修补了什么，如何证明？带日期的补丁记录、扫描结果和保存完好的日志可以回答这个问题，“我们觉得没问题”不行。

现在该怎么做？24 小时、72 小时和 7 天行动计划

以下步骤依据 PHP 项目的安全公告，以及 HKCERT、CSA 和 CISA 的指引整理。请把它们当作先后顺序，而不是可选菜单。

24 小时内：找出来、打补丁、重启

盘点你拥有或托管的每一个 PHP 运行时。先从面向互联网的服务器开始，把控制面板、设备、容器和第三方托管的网站都算上。以书面形式向每家网站托管商和软件厂商询问其补丁状态。
升级到已修复的版本。安装 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35，或者采用发行版、控制面板厂商提供的已修复软件包。Ubuntu 和 SUSE 等已发布更新。
重启所有 PHP 工作进程。旧进程不退出，修复就不会生效。请重启 PHP-FPM 进程池、使用 mod_php 的 Apache，以及任何长期运行的 PHP 进程。容器要重新构建并重新部署；基础镜像已打补丁，但容器仍在运行的话，等于没打。
优先修补 mod_php。Apache 搭配 mod_php 风险最高，这类服务器排在队列最前面。
凡使用厂商回移补丁的，按 CVE 编号而不是版本号来验证修复。

今天无法打补丁：先缩小暴露面

PHP 项目明确表示，没有任何配置变更能完全缓解这些漏洞。临时措施只能收窄特定的攻击路径。如果某个系统无法在数小时内更新，请尽可能多地采取下列措施，同时仍要安排升级：

让它下线或隔离。HKCERT 和 watchTowr 都建议，对无法立即修补的 PHP 系统，限制或取消其公网访问。这是唯一能消除风险（而不只是降低风险）的临时措施。
针对 CVE-2026-109619：在 `php.ini`、FPM 进程池或服务器配置中设置 `session.upload_progress.enabled=0`，然后重启所有工作进程。不要依赖 `ini_set()` 或 `.user.ini`。在 PHP 8.5 上，还要设置 `fatal_error_backtraces=0`。
针对 CVE-2026-109618：在网页服务器或代理层限制请求大小，包括请求体大小、字段数量、multipart 分段数量、请求头数量和嵌套深度。把 `post_max_size` 保持在较低水平（公告建议无上传时设为 8M，有上传时设为 32M）。通过容器或 cgroup 内存限制来约束工作进程，使其只终止受影响的那个进程。公告还提到可以设置 `memory_limit=-1`，但同时警告，仅靠这一项并不能让安装变得安全。
如有托管式 WAF 规则，请启用。Cloudflare 已部署临时规则；Google Cloud 建议使用 Cloud Armor 托管规则并设置请求体检查上限。把这些视为安全带，而不是修复。例如 CloudLinux 就指出，其防火墙规则暂时还无法覆盖两条攻击路径中的一条。

72 小时内：排查是否已经中招

利用尝试自10月21日起就有报告，Amazon 报告的最早一次尝试可追溯到10月17日。打补丁是关上门，但不能告诉你之前有没有人进来过。

在日志轮转之前留存日志。至少保留10月中旬以来的网页服务器、PHP-FPM、WAF 和防火墙日志。CSA 特别建议回溯检查到10月中旬的日志。
查找异常请求和进程行为。留意体积过大或格式异常的请求、集中出现的内存耗尽错误或工作进程崩溃，以及 PHP 或网页服务器进程衍生出 shell 或意外的子进程。
检查持久化痕迹。查看网站根目录和上传目录里是否有新增或被改动的 PHP 文件，是否有不明的定时任务、新的本地账户和意外的对外连接。英国 NCSC 特别提醒各机构留意后门。
发现异常就升级处置。如果发现入侵迹象，请隔离主机、保全证据并引入事件响应团队。从已知干净的镜像重建，比在线清理服务器更稳妥。

7 天内：补上结构性缺口

淘汰 PHP 8.1 及更旧的版本。回移补丁只是争取时间，无法让已终止支持的分支长期保持安全。由于 PHP 8.2 将于2026年12月31日终止支持，也要规划迁移。
补上资产盘点的缺口。如果这次事件让你发现了自己并不知道的 PHP，说明你的资产登记册并不完整。把内嵌系统和由厂商管理的系统加进去。
给补丁设定时限。对面向互联网的严重漏洞，定下书面的修复时间目标，以小时而不是下一个维护窗口为单位，并按此汇报。
记录你做了什么。保留一份带日期的记录，涵盖资产盘点、补丁时间、验证情况和日志审查。董事会、监管机构、客户和保险公司都会要求提供这份证据。

打补丁、回移补丁、缓解还是隔离：哪种方案适合你？

大多数环境会同时用到其中几种。以下是它们的对比。

四种应对方式对比

官方更新（8.5.12、8.4.27、8.3.36、8.2.35）：同时修复两个漏洞。需要重启，并做一次快速的应用冒烟测试。这是唯一完整的修复方式，也是所有受支持系统的默认选择。
厂商或发行版回移补丁：在不做大版本升级的前提下，修复旧分支上的两个漏洞。取决于厂商的支持情况；由于版本号可能不变，请按 CVE 编号验证。对 PHP 8.1、8.0 或 7.4 来说是合理的过渡方案，但不是最终归宿。
配置缓解与 WAF 规则：几分钟内就能收窄特定攻击路径。按 PHP 项目自己的说法并不完整，还可能影响正常的上传或进度条功能。只在准备更新期间使用。
隔离或临时关停：彻底消除互联网暴露，代价是可用性。适用于 PHP 7.3 及更旧版本、无法打补丁的设备，以及任何一天内无法更新的系统。欧洲和加拿大的若干公共机构在最初 48 小时内选择了这条路。

更大的教训：AI 压缩了补丁窗口

PHP2Shell 与普通的严重漏洞有两点不同。其一，这些漏洞是借助 AI 辅助工具发现的，而攻击者手里也有同样的工具。其二，信息泄露加上已修复版本提前发布，意味着攻击者数小时内就能对比新旧代码。HKCERT 自己的标题已直接点明：AI 同时在加速攻击与防御，并缩短了响应窗口。

对中型企业而言，实际后果是：“我们每月第二个星期二打补丁”已不足以作为面向互联网系统的安全策略。真正保护你的，是一条无论哪一天都能运转的短链条：

知道自己在运行什么。保持实时更新的资产清单，包括内嵌软件和第三方托管的软件。
看清哪些暴露在外。定期进行外部漏洞扫描，让严重问题先于攻击者被你发现。
给补丁设定时限。为严重漏洞的修复指定负责人并设定书面的时间目标，包含重启和验证步骤。
盯住攻击企图。保留日志并做好监控，让利用尝试能够被看到，而不是等收到勒索信才知道。

Brocent 能提供哪些帮助？

Brocent 为香港、中国内地、新加坡及更广泛的亚太地区企业提供管理型IT外包服务和网络安全服务。针对 PHP2Shell 这类事件，相关的服务包括：

暴露面检查：通过外部漏洞扫描找出面向互联网的 PHP 及其他严重暴露点，或选择范围更广的 IT 安全评估。
给补丁设定时限：管理型漏洞扫描与补丁管理，并提供补丁合规报告。如果只需要这项服务，请参阅补丁管理定价。
资产盘点与加固：通过 IT 评估与审计，把内嵌系统、控制面板和老旧应用纳入同一份登记册，并规划如何从已终止支持的 PHP 迁出。
边界防护：网络安全方案，包括防火墙和 WAF 规则，在系统完成更新之前作为补偿性控制措施。

如果你不确定自己环境中的某个系统是否受影响，欢迎联系 Brocent，我们的团队会协助你逐项落实上述清单。

常见问题

PHP2Shell 是什么？

PHP2Shell 是 CVE-2026-109618 和 CVE-2026-109619 的通用称呼，指 PHP 解释器中的两个严重漏洞，于2026年10月21日披露并修复。它们可能使未经身份验证的攻击者在运行 PHP 并处理网页请求的服务器上执行代码。

更新 WordPress、Drupal 或插件能解决问题吗？

不能。漏洞存在于 PHP 引擎本身，位于应用程序之下。只有更新 PHP 运行时，或使用回移了修复的厂商软件包，才能封堵它们。CMS 和插件当然也要保持更新，但那是另一项独立的工作。

哪些 PHP 版本修复了 PHP2Shell？

PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。对于 PHP 8.1、8.0 和 7.4，请使用同时列出两个 CVE 编号的发行版或长期支持厂商软件包。PHP 7.3 及更旧版本没有修复，应升级或隔离。

PHP2Shell 正在被利用吗？

是的，多个来源都有报告。watchTowr 和 Cloudflare 报告自2026年10月21日起出现利用尝试，Amazon 报告了日期为10月17日的一次尝试，HKCERT 于10月23日更新的公告则指出这些漏洞正在被实际利用。截至10月22日，CISA 尚未把任一 CVE 列入已知被利用漏洞目录，因此局势仍在发展。