这两天 PHP 安全公告里出现了两个严重漏洞：CVE-2026-109618 和 CVE-2026-109619。它们都在 PHP 核心处理请求、内存和错误状态的路径上，可能让未登录的远程请求触发代码执行。媒体常把这组问题合称为 PHP2Shell；这个名字容易让人以为只有一个漏洞，实际对应的是两条不同的缺陷路径。

我把 PHP 官方公告、PHP Foundation 的事后说明，以及研究团队和云服务商公开的遥测信息按时间整理在这里。本文信息截至 2026 年 10 月 22 日。公开报告可以说明漏洞能造成什么、研究人员观察到了什么，但不能据此推断某个具体网站已经被入侵。

先说结论：这是 PHP 运行时问题，不是某个 CMS 插件问题

PHP 官方将两项漏洞都评为 CVSS v4.0 9.2（Critical）。在受影响配置和请求路径下，攻击者不需要先登录，就可能通过特制 HTTP 请求造成拒绝服务、读取 PHP worker 可访问的敏感内存，或进一步执行代码。

漏洞 官方描述 简要机制
CVE-2026-109618 RCE via OOM corruption 内存分配失败中断请求时，某些内部数据尚未完整初始化；后续清理流程仍把它当作有效状态处理。
CVE-2026-109619 RCE via stale global state 请求结束后，worker 中的全局状态仍指向已经释放的请求内存；同一 worker 处理后续请求时可能再次使用这段失效状态。

影响面在 PHP 运行时，因此 WordPress、Drupal、Joomla 等应用并不是漏洞根源，也不能仅靠升级 CMS 或插件修复。PHP 官方特别指出，所有处理 Web 请求的 PHP 安装都应检查；Apache mod_php 的风险最高，官方公告称已有在默认设置下、应用代码运行前触发的演示。PHP-FPM 等运行方式也有相应攻击路径，具体暴露条件会受到 SAPI、配置和应用代码影响。

使用 Swoole / OpenSwoole 的 PHP 服务是否受影响？

这部分目前不能简单回答“安全”或“必然受影响”。PHP 官方公告列出的 Web 运行方式包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed，没有单独列出 Swoole 或 OpenSwoole；我也没有找到 PHP 或 Swoole 维护者针对 PHP2Shell 发布的、明确排除 Swoole 的兼容性声明。因此，不能因为服务使用 Swoole 就把它从排查范围中排除。

判断重点在于服务实际加载的 PHP runtime，以及请求是否会经过受影响的 PHP 核心路径：

  • Swoole 是 PHP 扩展和常驻 worker 运行模型。只要底层 PHP 版本落在受影响范围，就应按“潜在受影响”处理，先确认对应 PHP 二进制和扩展构建是否包含修复；升级 Swoole 扩展本身不能替代升级 PHP runtime。
  • Swoole 的 HTTP 服务使用自己的服务器和请求解析流程，和 PHP-FPM 的 SAPI 路径不完全相同。公开资料没有给出足够证据证明每一种 Swoole HTTP 配置都能触发两个 CVE，也没有证据证明它们全部免疫，所以这里不能把 PHP-FPM 的复现条件直接套用到 Swoole。
  • CVE-2026-109619 涉及跨请求复用的 stale global state，而 Swoole worker 通常会持续处理多个请求；这使得“长驻 worker 是否正确清理状态”成为必须验证的风险点，但这是基于运行模型的风险判断，不是官方确认的 Swoole 专属利用路径。

实际处置可以按下面的顺序做：

  1. 在实际运行环境中检查 php -v、php --ri swoole 或 php --ri openswoole，确认不是只更新了系统里未被服务加载的另一套 PHP。
  2. 将底层 PHP 更新到 8.5.12、8.4.27、8.3.36 或 8.2.35，或采用发行版/长期支持供应商提供的回移补丁；随后重启全部 Swoole worker，让旧的 PHP 进程退出。
  3. 检查服务是否开放 multipart/form-data、文件上传、session upload progress，以及是否存在会在 worker 间长期保留状态的扩展或全局对象。不要在生产环境直接运行网上的 PoC；应在隔离测试环境验证升级前后的请求错误、worker 重启和异常进程行为。
  4. 在无法立即升级时，按 PHP 官方公告评估临时限制请求体和上传能力、关闭 session.upload_progress 等措施。它们只覆盖部分路径，不能证明 Swoole 服务已经安全，也不能替代补丁。

因此，对 Swoole 服务更准确的结论是：没有公开资料证明它一定受影响或一定不受影响；只要底层 PHP 版本受影响，就应先按潜在受影响服务升级 PHP、重启常驻 worker，并向 Swoole/OpenSwoole 维护者或发行版供应商确认具体版本。

从漏洞线索到修复发布：公开时间线

下面把“研究发现”“报告给维护者”“公开披露”和“攻击观测”分开列出。前两类主要来自参与披露的研究方与 PHP Foundation；攻击观测来自 AWS 和 Cloudflare 自己的遥测，不能等同于对全网的统计。

日期（UTC） 事件
2024 年 PHP Foundation 组织的外部安全审计由 Quarkslab 执行。PHP 核心开发者在修复审计发现的问题时，注意到后来归入 OOM 漏洞的早期迹象；当时还没有找到明确的远程代码执行路径，修复方案也牵涉兼容性和扩展生态，工作一度停滞。
2026-07-30 PHP Foundation 后来披露，安全公司 Calif 在 OpenAI 的 Patch the Planet 项目中开始审计 PHP。
2026-08-11 PHP Foundation 记载，Calif 研究员 Ryan A 报告了与 OOM 问题同源的无条件 RCE；OpenAI 同日独立报告了相同根因。这里的“无条件”是研究报告中的漏洞描述，不代表所有 PHP 部署都能用同一个请求稳定利用。
2026-08-19 至 08-24 Wiz Research 记录：8 月 19 日发现相关 PHP 漏洞，随后在 Drupal、WordPress 上验证未认证 RCE，并于 8 月 24 日向 PHP 安全团队报告。PHP Foundation 的复盘也列出 Wiz 于 8 月 24 日提供进一步攻击路径。
2026-09-18 PHP Foundation 记载 OpenAI 提供了进一步攻击路径报告。
2026-09-21 Wiz 的时间线称 PHP 确认其报告并开始协调修复。
2026-10-20 约 15:00 PHP Foundation 称，两个 CVE 编号开始在论坛和社交媒体流传，但当时流传的发布时间及 CVSS 分数有误，且没有技术细节。PHP 团队随后提前发布预告，并把原定 10 月 22 日的公告提前到 10 月 21 日。
2026-10-21 07:41 PHP Foundation 称 Chainguard 提前公开了包含修复的构建镜像，早于协调披露时间。随后 PoC 传播加快。
2026-10-21 13:40–14:00 PHP 安全更新和详细公告公开。ENISA 记录的更新发布时间为 13:40 UTC；PHP 原定发布时间是 14:00 UTC。官方发布 PHP 8.5.12、8.4.27、8.3.36、8.2.35。
2026-10-21 Cloudflare 表示，在漏洞正式披露前已经观察到针对其客户的攻击流量，并在披露前约 9 小时启用 WAF 防护。AWS 表示，其 MadPot 蜜罐发现了最早可追溯到 10 月 17 日的利用尝试。

时间线里有个值得留意的差异：研究人员报告漏洞数周后，公开修复才发布；而补丁构建及技术线索在正式披露前已出现。PHP Foundation 承认，早期修复工作受制于核心代码的兼容性取舍、专家人手不足和决策机制，进度曾经反复。这不是简单的“发现后马上改一行代码”，而是需要维护者、研究团队、发行版和托管服务商共同准备的协调披露过程。

谁发现了它？

公开资料显示，这不是单一研究者一人发现并完成修复的故事：

  • Calif：PHP Foundation 点名感谢研究员 Ryan A；Calif 在 OpenAI 的 Patch the Planet 项目中开展审计。OpenAI 称其模型协助发现了关键缺陷，并参与研究协调和修复验证。
  • OpenAI：PHP Foundation 表示 OpenAI 在 8 月 11 日独立报告了相同根因，并在之后提交了其他攻击路径。OpenAI 的公开复盘称，Calif 使用 GPT-5.6 Sol 发现了关键问题。
  • Wiz Research：独立发现并报告相关漏洞，公开了在 Drupal 和 WordPress 上验证未认证 RCE 的研究过程。Wiz 的文章署名 Sagi Tzadik、Shir Tamari、Nir Ohfeld、Tomer Schwartz。
  • Quarkslab 与 PHP 维护者：2024 年审计的线索，以及 PHP Foundation 受聘核心开发者的分析，帮助暴露了 OOM 根因；最终补丁由 PHP 维护者主导设计和发布。GitHub 安全公告另列有多位报告者和修复开发者账号。

因此，比较准确的说法是：漏洞由外部审计、研究团队和 AI 辅助研究先后揭示；漏洞验证、根因归并、兼容性权衡和修复发布由 PHP 维护者与协作方共同完成。AI 参与了发现和分析，但不应把修复归功于模型本身。

攻击已经开始了吗？

已有攻击尝试的公开观测，但“攻击尝试”不等于“已确认入侵”。 截至本文资料时间，几组报告需要分别理解：

  1. AWS：存在披露前的蜜罐命中。 Amazon Threat Intelligence 称，其 MadPot 蜜罐记录到 10 月 17 日的一次利用尝试，之后在 10 月 21 日补丁公开前后又看到来自其他匿名化基础设施的尝试。AWS 明确表示，正在分析这些请求，尚不能确定它们在真实系统上是否会成功；蜜罐记录也不能证明某个客户已经失陷。
  2. Cloudflare：看到针对客户的攻击流量。 Cloudflare 表示，漏洞泄漏期间就观察到攻击流量，并看到攻击者修改 payload 试图绕过规则。这证明有人在尝试利用，但其博客没有声称每一次请求都成功执行了代码。
  3. PHP 安全团队：披露时没有发现可用的公开 PoC。 PHP Foundation 的复盘说，团队在披露前检查流传的 PoC，当时没有找到可工作的公开利用代码。这个说法与 AWS 的蜜罐命中并不矛盾：一个是维护团队检查公开 PoC 的结果，一个是云厂商自己的传感器观察到的流量，时间、样本和判定口径不同。
  4. 成功利用能力已被研究演示。 Wiz 和 NHS England 的公告记录了研究人员在 WordPress、Drupal、Joomla 等环境中的成功 RCE 演示。这说明漏洞确实可以被利用，不代表这些应用或真实网站都已经遭入侵。

所以，如果问题是“有没有人开始发利用请求”，答案是有；如果问题是“已有多少真实网站被攻陷”，我没有找到截至 10 月 22 日可核实的统一统计或足以证明大规模成功入侵的公开数据。运营方应结合自己的访问日志、PHP worker 行为、异常进程和文件变更判断，不能只看 CVE 公告或 WAF 告警下结论。

影响范围与修复版本

PHP 官方当前列出的修复版本如下：

分支 受影响版本 首个修复版本
PHP 8.5 8.5.0–8.5.11 8.5.12
PHP 8.4 8.4.0–8.4.26 8.4.27
PHP 8.3 8.3.0–8.3.35 8.3.36
PHP 8.2 8.2.0–8.2.34 8.2.35
PHP 8.1 及更早 受影响，已停止 PHP 项目常规安全更新 联系发行版或长期支持供应商确认回移补丁；否则迁移到受支持分支

PHP 官方还为自行构建、暂时无法从发行版取得更新的用户提供了 PHP 7.4、8.0、8.1 的最小源码回移补丁。发行版和长期支持供应商也可能有自己的包版本号，所以不要只根据上游版本号判断；应查服务器实际运行的 PHP 包及供应商公告。PHP 8.2 的安全支持计划于 2026 年 12 月 31 日结束，升级时也应考虑后续支持周期。

受影响的是实际处理 Web 请求的 PHP runtime。一个站点可能有多个 PHP-FPM pool、容器、主机或控制面板托管版本；更新命令成功并不自动证明线上 worker 已换成新二进制。应核对实际入口使用的版本，并按发行版或托管平台流程重启/滚动替换 worker。若 PHP 由主机商管理，需要向服务商确认对应运行时已修复。

临时缓解不能替代升级

PHP 官方给出的配置缓解只针对特定攻击路径，并明确说明它们不能让安装变安全。例如，针对 OOM 路径可调整 PHP 内存限制和请求体限制；针对 stale global state 路径可在适当的启动配置中关闭 session.upload_progress 并重启 worker。具体配置需按 PHP 官方公告和实际业务验证，避免直接照抄后造成上传功能中断或其他可用性问题。

WAF 规则可以作为额外防线。Cloudflare 和 AWS 都发布了相关防护信息，但它们不是完整补丁；请求变体、不同 SAPI 和应用路径会影响覆盖情况。PHP 官方的结论很明确：升级到已修复的 PHP 版本才是完整修复。对于无法及时更新的互联网暴露系统，NHS England 和英国 NCSC 建议评估暂时下线的风险控制措施。

我从这次事件里看到的几个实际问题

第一，资产清单要落到“哪台机器、哪个容器、哪个 FPM pool 正在处理请求”，而不是只知道项目用了 PHP。框架依赖清单和代码仓库里的 composer.json 不能替代对运行时的盘点。

第二，事件响应时间应从最早可能的攻击活动回溯。AWS 报告的 10 月 17 日早于 10 月 20 日的泄漏和 10 月 21 日公开披露；排查窗口不应只从公告发布日期开始。各组织应根据自己的日志留存情况决定能回看多久。

第三，升级后要验证运行中的 worker，而不是只看包管理器输出。长驻 worker 可能仍需重启或滚动替换；托管环境还要确认供应商实际部署完成。

第四，安全信息要区分“已证明可利用”“看到利用尝试”和“确认业务被攻陷”。这几个结论的证据门槛不同，混写会让风险判断失真。

这次事件也提醒我，基础运行时的安全维护依赖长期投入：PHP Foundation 在复盘中坦言，复杂兼容性问题、人手和决策机制曾拖慢修复。AI 能帮助研究者更快理解和验证漏洞，但维护者仍然要承担修复设计、测试和生态协同的工作。

参考资料

说明：本文依据上述公开资料进行整理，不代表对任何具体服务器的扫描、测试或入侵判断。版本与缓解建议可能随发行版、托管商和后续公告更新；实际处置以 PHP 官方和所用供应商的最新说明为准。