PHP2Shell：AI 两天挖出 9.2 分漏洞，让全球 70% 网站连夜打补丁

一句话概括：2026 年 10 月 21 日，PHP 官方深夜发布紧急安全更新，修复两个 CVSS v4.0 评分 9.2 的远程代码执行漏洞——它们不是人挖出来的，是 AI 挖出来的。这两个洞埋在 PHP 引擎里二十多年，一个核心开发者两年前找过却没找到利用路径，而 AI 用了两天。1Panel 已经把修复版本封装好，推到了你的应用商店里。

一、10 月 21 日这一天，发生了两件事

这两件事是一体两面，指向同一个判断：AI 正在从"写代码的工具"，变成"互联网基础设施的直接参与者"。

第一件：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。

第二件：OpenAI 公开了 Patch the Planet 框架。

OpenAI 承认，这两个洞是它的模型发现的——由安全公司 Calif 的研究者用 GPT-5.6 Sol 在审计 PHP 时挖出，Wiz 也独立发现了同样的两个漏洞。OpenAI 牵头，花了两个月时间协调 PHP 维护者、云厂商、安全公司和政府机构，在公开披露之前把补丁和防护措施全部准备好。

前一件是结果，后一件是方法。前者让全球 69.3% 的网站连夜爬起来打补丁；后者解释了为什么这种事以后会越来越多。

下面按顺序讲：先讲最硬的漏洞本身，再讲它是怎么被 AI 挖出来的，然后讲这件事真正的意义，最后落到你的服务器上该干什么。

二、PHP2Shell：两个洞，一个比一个底层

先把基本盘摆清楚。

项目 内容
漏洞编号 CVE-2026-109618、CVE-2026-109619
社区命名 PHP2Shell
CVSS v4.0 9.2（严重），两项一致
漏洞类型 未授权远程代码执行（RCE）
影响范围 所有处理 Web 请求的 PHP 安装：PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed
风险最高 Apache mod_php——已有验证案例表明，未认证请求可在应用代码运行之前触发漏洞
影响面 W3Techs 可识别服务端语言的网站中，69.3% 使用 PHP
官方修复 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12

CVE-2026-109618：内存耗尽时的"计数先加、数据后填"

这个洞的原理，值得完整讲一遍，因为它漂亮得有点吓人。

PHP 给每个 Web 请求划了一道内存额度，默认是 128 MiB。用光了就得中断处理、报错、清理——这种情况叫内存耗尽（OOM）。

问题出现在哈希表插入新记录的那几行代码上。正常逻辑应该是：

  1. 申请一块内存
  2. 把内容填进去
  3. 记录数 +1

而 PHP 实际的执行顺序是：

  1. 记录数 +1
  2. 申请内存
  3. 填内容

这个顺序在 99.9999% 的情况下没有区别。但如果第 2 步"申请内存"的时候，额度正好用完了呢？

程序会立刻跳走去执行 OOM 处理流程。这时候计数已经加了，但那条记录的内存还没申请、内容还没填。 清理程序照着计数去遍历，就会把一块尚未初始化的内存当成一条有效记录来使用。

打个比方：一张表格，你先在"共 N 行"上写了个 N+1，然后才去填第 N+1 行。写到一半被人叫走了。回来的人看到"共 N+1 行"，就把第 N+1 行当成填完的正式记录拿去用了。

关键在于：攻击者能主动制造这个"正好用完"的瞬间。

Calif 披露的一条攻击路径里，不到 8 MiB 的请求数据，处理时足以耗尽 PHP 默认的 128 MiB 内存额度。原因是请求进入 PHP 后会被拆成大量记录，每条记录都要额外占用内存——攻击者利用这层放大效应，精确地让程序在特定的那一步耗尽额度。

把这种错误变成真正的远程代码执行，还需要安排好相关内存的内容、满足具体的运行条件。研究者已经在受影响的部署中，让程序执行了攻击者指定的代码。

Wiz 的验证更直接：他们用当时最新版的 WordPress、Drupal、Joomla 镜像搭建测试环境，复现了无需登录的远程攻击，还验证了从内存中读取密码、令牌和 API 密钥的攻击路径。

也就是说，即使你的页面上只写了一行 Hello World，在某些 Apache + mod_php 部署下也可能中招——因为攻击发生在你自己的程序启动之前。

CVE-2026-109619：请求结束了，旧地址还留着

第二个洞来自同一轮审计，但在另一处代码里——负责记录文件上传进度的那部分。

一次请求异常结束时，相关内存被释放了，但处理请求的程序还保留着旧的内存地址。同一个 worker 进程处理下一个请求时，可能在正常初始化重置之前，就用到了这些已经失效的状态。

这本质上是"请求级全局状态残留"问题。在多请求复用的进程模型里（PHP-FPM、mod_php 都是），这类问题的杀伤力被显著放大——因为你不知道上一个请求是谁发的。

为什么这两个洞特别难对付

PHP 官方这次把修复说成是"需要对 PHP 引擎做一次重大改动"（a major change to the PHP engine）。这就是为什么从 8 月发现到 10 月发版，中间隔了整整两个多月——不是拖，是真的难改。

也正因为难改、影响面又覆盖大半个互联网，这次披露走的是全球协同路线，而不是"发个公告就完事"。参与准备防护的包括 Google Cloud、Cloudflare、AWS、Microsoft、Automattic、Fastly、Akamai、Imperva、Vercel 等；政府侧则协调了白宫相关团队、ONCD（国家网络总监办公室）、CISA（网络安全与基础设施安全局）以及国际伙伴，用来把指引推送到关键基础设施运营方手里。

三、真正的主角：AI 是怎么把它挖出来的

漏洞本身年年有，这次不一样的地方在于挖洞的人。

完整时间线

时间 事件
2004 年 PHP 的内存限制机制就被发现存在远程攻击面——这是二十多年前的老问题域
2024 年 有 PHP 核心开发者试图利用同类问题，花了很久也没找到可利用路径，最终放弃
2026 年 6 月 OpenAI 宣布 Patch the Planet 安全计划：用 AI 智能体协同发现并修复关键开源漏洞
7 月 30 日 Calif 研究者 Ryan Austin 开始审计 PHP，参与 Patch the Planet 计划
8 月 1 日 找到第一个可触发"内存耗尽"的入口——开始审计后第 2 天
8 月 11 日 Calif 向 PHP 报告；同一天 OpenAI 自己的研究人员也独立报上了同一个问题
8 月 15 日 PHP 确认：Calif 提交的攻击演示确实能跑通
8 月 19 日 Wiz 独立发现该漏洞；8 月 24 日报给 PHP
8 月 21 日 Calif 发现第二个漏洞（CVE-2026-109619）
9 月 18 日 又有更多攻击路径被报上来
10 月 21 日 PHP 紧急发布修复版本，全球协同披露启动

"两天"这个数字，是整件事最刺眼的地方。

2024 年，一个熟悉 PHP 内核的核心开发者，专门去找这个洞，找了很久，没找到利用路径。2026 年，一个人加上一个模型，从开始审计到找到第一个入口：两天。

关键手法：把发现写成 SKILL.md，让 Agent 顺着线索继续挖

这里有个细节，比"AI 找到了漏洞"本身更值得注意。

研究者在挖出第一个洞之后，并没有就此收工。他们让模型把刚刚发现的这个错误模式写成一份 SKILL.md——一份可以被反复调用、反复使用的审计指引——然后让 Agent 拿着这份指引，沿着同样的线索在整个代码库里继续查。

结果：Agent 在负责记录文件上传进度的代码里，找到了第二个问题。

也就是说，这不是"模型碰巧看到一个 bug"，而是一次发现被沉淀成了可复用的方法论，方法论又自动产出了下一次发现。找到的不再是一个点，而是一整类问题。

这是 AI 审计和传统人工审计最本质的区别：人挖到一个洞，经验留在脑子里；AI 挖到一个洞，经验变成一份可以立刻分发给一万个 Agent 的文件。

背景补充：这不是孤例

Anthropic 在这个月公布过一个数字：从 2025 年 11 月到 2026 年 10 月初，它的模型在开源项目里累计找出了 29,439 条候选漏洞线索。

PHP2Shell 只是其中被完整走完流程、公开披露的那一个。OpenAI 在官方博客里也明确说了：

"这些漏洞只是我们已经发现并正在修复的若干个重大漏洞中的一部分，我们预计类似的发现在未来几个月会急剧增加。"

四、这件事的意义：漏洞经济学被改写了

如果只把 PHP2Shell 当成"又一个高危漏洞"，你会低估它。它真正改变的是四件事——以及由此逼出来的一个新应对框架。

1. 找漏洞的成本，塌了

互联网的底层，其实是建立在一堆没人付钱、也没几个人认真看的代码上的。

这么多年它大体上没出事，原因特别朴素：找漏洞太贵了。

能在 PHP 内核、OpenSSL 这种地方找到并利用内存漏洞的人，全世界可能就几百个。他们的时间极贵，一个洞要磨几个月。所以很多雷可以安安静静地埋上二十年——不是因为藏得好，是因为真的没人愿意去搭理它们，成本太高了。

而 AI 让过去所有"贵"的东西，都变得不再贵。

这次的案例给了个非常直观的锚点：两个月 vs 二十年。一个 2004 年就被发现有问题域的老机制，一个 2024 年有人专门找但没找到利用路径的洞，在 2026 年被 AI 在两天内攻破。

当发现成本从"几个月的人力"降到"几小时的 GPU 时间"，所有历史的欠账都会在同一时间被翻出来。

2. 攻防之间，多出一个新东西：Defender's Window

这次披露出现了一个此前很少被认真讨论的概念——Defender's Window（防御者窗口）。

传统的漏洞披露逻辑是：发现 → 立刻公开 → 全世界的攻击者和管理员同时开始赛跑。管理员通常输。

这次不一样。AI 在 8 月找到漏洞，公开披露在 10 月。这两个月里：

  • PHP 维护者开发并测试修复（还做了对抗性测试，用前沿模型去找绕过补丁的方法和同类变体）；
  • 云厂商准备好了 WAF 规则和临时缓解措施；
  • 发行版准备好了旧版本的回补补丁；
  • 政府机构准备好了向关键基础设施运营方推送的指引。

OpenAI 的原话是："据我们所知，前沿 AI 在攻击者之前发现了这些漏洞"——正是这个时间差，给了防御者准备的机会。

这是一个全新的可能性：AI 不仅能挖洞，还能为挖洞这件事争取到修复时间。

3. 同一把刀，两边都能用

OpenAI

必须说清楚另一面。OpenAI 自己在公告里也很坦白：

"这凸显了 AI 如何能够发现具有互联网规模影响的安全漏洞，但同样的能力也可以帮助攻击者快速开发攻击工具和漏洞利用程序。"

所以不要把这件事理解成"安全从此变得容易了"。准确的理解是：攻防双方的能力曲线同时被抬高了，而谁能先跑完"发现 → 修复 → 部署"这个闭环，谁才真的赢。

这也是 OpenAI 宣布投入 10 亿美元补贴"Daybreak for Frontline Defenders"的原因——把这套能力送到那些保护关键服务、但安全资源有限的组织手里。因为如果只有攻击方和巨头拥有这个能力，那不是防御增强，是失衡加剧。

4. 真正的瓶颈，已经从"发现"转移到了"修复"

这是整件事里最尴尬、也最重要的一层。

PHP 基金会自己承认：这个内存问题 2024 年就有苗头，拖到今天才修，一个重要原因是人手不够。复盘的最后，他们几乎是在求助，希望公司、主机商和政府来赞助。

Hacker News 上有人翻出了 Debian 上负责给 PHP 打包的维护者的赞助页面，吐槽了一句：一个月连 700 美元都不到。

而全世界的服务器，真的就在等这些人半夜起来发版。

于是出现一个极其别扭的结构：

  • 发现能力：被 AI 抬高了几个数量级，而且还在加速；
  • 修复能力：还是靠几个志愿者用爱发电；
  • 部署能力：靠全球几千万个运维自己去点"更新"。

当发现速度远远超过修复和部署速度时，堆积的不是安全感，是风险。 AI 每个月挖出几百个高危漏洞，而维护者一年只能高质量地修好十几个——这个剪刀差才是未来几年网络安全真正的难题。

5. 于是有了 Patch the Planet 的五阶段框架

OpenAI 很清楚这个问题，所以它这次推的不只是一个漏洞，而是一套流程。它把这个框架提了出来，并公开请求安全社区一起改进：

阶段 做什么 谁参与
1. 验证并修复上游漏洞 确认发现、评估影响、开发并测试修复，包括用前沿模型做对抗性测试（找绕过补丁的方法和相关变体） 维护者、研究者、技术伙伴
2. 给受影响组织留出行动时间 判断哪些组织需要提前获知以准备防护，协助外联、信息共享协议和跨团队协调 OpenAI、维护者、分发商
3. 与政府伙伴协同，保护关键系统 让安全指引触达负责关键基础设施和基本服务的组织 CISA、ONCD 等政府机构
4. 在受影响产品中准备更新 分发商为旧版本适配补丁、主机商测试缓解措施、安全厂商准备检测与拦截规则（如 WAF） 云厂商、发行版、安全厂商
5. 补丁就绪后，公开指引并支持部署 公开披露、提供版本检查工具、指导验证修复是否生效 全体

配套动作包括：发布 PHP 版本检查工具，以及即将推出的 Codex skill——帮运维识别可能存在风险的 PHP 版本，并结合 PHP 官方和其服务商的指引判断该打哪个补丁。

一句话概括这套框架想做的事：把"修一个洞"从一次英雄主义的救火，变成一条可以规模化的流水线。

五、落到你的服务器：1Panel 已正式发布 PHP 安全升级

1Panel

前面讲的都是行业层面的事。如果你的服务器上跑着 PHP，这一段是你要执行的。

1Panel 已经在 10 月 21 日同步完成了 PHP 运行环境的版本升级，并发布了正式的安全升级说明。使用受影响版本的用户请及时更新并完成版本切换。

PHP 官方修复版本（1Panel 已完成镜像封装）

PHP 分支 需升级到 说明
PHP 8.2.x 8.2.35 包含 CVE-2026-109618 与 CVE-2026-109619 修复
PHP 8.3.x 8.3.36 同上
PHP 8.4.x 8.4.27 同上
PHP 8.5.x 8.5.12 同上

对应的 1Panel 运行环境镜像已经封装完成，命名规则为 1panel/php:<版本>，例如 1panel/php:8.2.35。

还在用 PHP 7.4 / 8.0 / 8.1 怎么办

PHP 官方已经不再为 7.4、8.0、8.1 这三个分支发布新版本——也就是说，官方不会为它们提供这两个漏洞的修复。

1Panel 为仍在使用这些版本的用户，提供了已回补本次漏洞的安全补丁镜像：

PHP 分支 1Panel 维护版本 上一个版本
PHP 7.4 7.4.34 7.4.33
PHP 8.0 8.0.31 8.0.30
PHP 8.1 8.1.35 8.1.34

⚠️ 务必注意：1Panel 的运行环境镜像均由 1Panel 统一封装。其中 8.2–8.5 基于 PHP 官方安全版本；而 7.4.34、8.0.31、8.1.35 是 PHP 官方停止该分支发布新版本后，1Panel 基于官方提供的最小化源码回补封装的维护版本标签，并非 PHP 官方发布版本。

建议仍在使用 7.4 / 8.0 / 8.1 的业务先升级到对应补丁版本止血，然后尽快规划迁移到 PHP 官方仍在维护的版本。补丁能挡住这一次，挡不住下一次。

四步完成升级

  1. 进入 「应用商店」；
  2. 点击 「更新远程应用」 按钮，获取最新应用列表；
  3. 在运行环境配置中，将版本切换至新版本（如果编辑时获取不到新版本，可以先切换一下大版本再切回来）；
  4. 重启相关项目或服务，确认业务运行正常。

1Panel 的安全建议

  • PHP 8.2 及以上：升级至对应版本的 1Panel 运行环境镜像（基于 PHP 官方安全版本封装）；
  • PHP 7.4 / 8.0 / 8.1：先升级至 1Panel 的安全补丁镜像，并尽快规划迁移至 PHP 官方仍受支持的版本；
  • 尤其注意：面向公网提供 Web 服务的 PHP 环境，本次两项漏洞风险极高，建议尽快完成安全更新。

1Panel 表示将持续关注 PHP 等运行环境的安全更新，并及时同步相关版本。

六、现在该做的三件事

1. 今天就查版本。 面向公网的 PHP 服务优先。用 OpenAI 发布的 PHP 版本检查工具扫一遍，或者直接上服务器 php -v。只要不在 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 及对应补丁版本上，就处于暴露状态。

2. 升不动的话，先上缓解措施。 Cloudflare、Akamai、Imperva、Fastly 等厂商已经准备了 WAF 规则和检测手段。改不了版本的时候，先让规则挡在前面。

3. 重新评估你的"老旧版本债务"。 这次最该记住的不是这两个 CVE，而是：AI 让"没人发现的旧洞"变成了一个即将到期的负债。 那些你一直拖着没升的 PHP 7.4、没维护的内部系统、没人看的依赖，它们的安全性假设建立在"没人有空来挖它"之上——这个假设从 2026 年开始不成立了。

写在最后

2026 年 10 月 21 日这一天，值得记住的不是"PHP 出了个洞"。高危漏洞年年有，可这一个不一样——它不是人挖出来的。

值得记住的是这个画面：一个人加一个模型，用两天时间，刨出了埋在 PHP 引擎里二十多年、一个核心开发者两年前找过却没找到利用路径的洞；然后用了两个月时间，让全世界的云厂商、安全公司和政府机构，在这个洞被公开之前，就把补丁准备好了。

AI 发现漏洞这件事的意义，从来不只是"更快"。它改变的是三个基本盘：

  • 成本：找洞从"几百个人几个月"变成"几小时 GPU 时间"；
  • 时序：防御者第一次可能跑在攻击者前面，于是有了 Defender's Window；
  • 责任：当发现能力暴涨而修复能力没涨，我们欠开源维护者的那笔账，终于到了必须还的时候。

PHP 基金会在复盘里求助，Debian 的 PHP 打包维护者月赞助不到 700 美元——而全球 69.3% 的网站，正跑在这些代码上。

下一个 PHP2Shell 已经在路上了。OpenAI 说得很直白：类似的发现在未来几个月会急剧增加。

所以真正的问题不是"下一个洞在哪"，而是：当 AI 把全世界的雷都翻出来的时候，我们有足够多的人去拆吗？

posted @ 2026-10-22 10:24  小白跃升坊  阅读(71)  评论(2)    收藏  举报