PHP2Shell 怎么被挖出来的？起底 OpenAI「修补地球」计划，它还修复了哪些严重漏洞？
这两天，很多团队都在连夜升级 PHP，就是那两个 9.2 分的漏洞 PHP2Shell，折腾了大半个互联网。
事后看各方披露，最先挖出这批漏洞的，是 OpenAI 一个叫“修补地球”（Patch the Planet）的计划。这个计划今年才启动，知道的人还不多。它的目标很明确：帮助维护者加固这个世界赖以生存的关键开源软件。方式是用最先进的网络安全大模型做安全研究，再结合专家人工审核，不仅识别漏洞，也帮助修复。
为什么会有「修补地球」
现在 AI 找漏洞的能力，已经不需要再多论证了。大模型可以在几千万行代码里定位可疑位置，能自动生成漏洞利用程序（exploit）去验证，也能顺着一个已知漏洞去找它的各种变体。
但问题出在发现之后。
换句话说：AI 正在加速漏洞发现，但“发现”本身保护不了用户。AI 挖出大量漏洞后，开源项目维护者被迫用同样的时间和资源，处理更多、更快的报告。
这个压力有多大，可以看 PHP 自己公布的数字：从 7 月 1 日到 10 月 21 日，PHP 安全团队发布了 15 个 CVE；同期处理掉的报告里，有 100 多份最终被判定为无效、重复或者根本复现不出来。十份报告里一份真货。而这十份，还得一份一份看，因为不看就不知道哪份是真的。
AI 让每个人都变成了「能提交漏洞报告的人」，门槛低到不能再低。结果就是维护者收到的是一个越来越大的漏斗，但漏斗底下接的人没变多。
更麻烦的是，AI 生成的报告质量参差不齐。大模型很擅长“看起来像个漏洞”，不擅长“确认它是个漏洞”。中间的复核成本，全部落在维护者身上。
所以真正的瓶颈早就换了地方：不是“找不到”，是“修不动”。
是的，找漏洞这件事已经被 AI 打下来了，修漏洞这件事没有。它需要的还是那几个既懂整个代码库、又有权限拍板的人，而这样的人，每个项目都只有那么两三个。
「修补地球」就是冲着这个来的，OpenAI 说这个计划是为了减轻维护者的负担，而不是增加负担。同时 OpenAI 也承认这把刀是双面的。AI 能发现波及整个互联网的漏洞，同样的能力也能帮攻击者快速做出攻击工具和漏洞利用程序。所以真正要抢的不是"谁先发现"，而是谁先把补丁发出去。
他们的判断是：接下来几个月，这类发现会大幅增加。
它怎么解决“修不动”的问题
首先 OpenAI 把这个计划挂在 Daybreak 下面，主力执行方是安全公司 Trail of Bits，对方为第一波行动把整个安全研究团队都投了进来。另外两家合作方是 HackerOne 和 Calif，负责漏洞分诊（triage）、协调披露（coordinated disclosure）和一些定向的漏洞挖掘。
接着他们选了九个初始参与项目：cURL、NATS Server、pyca/cryptography、Sigstore、aiohttp、Go、freenginx、Python 和 python.org。
这份名单的取向很清楚，全是网络、密码学、软件供应链和语言基础设施。它们不是最出名的那批应用，而是被最多下游产品和服务使用的最多互联网基础设施。修好其中一个，受益的是一大片。后面还会有更多项目加入，PHP 就是后续进去的那一批。
具体做法可以概括为四条原则。
第一，先问维护者要什么，而不是带着结果上门。
每一轮合作都从跟维护者坐下来聊开始：这个项目现在缺什么、偏好什么样的补丁风格、精力最该花在哪儿，是漏洞验证、补丁开发、CI/CD 改进，还是长期的安全工程。
这条看着像流程，其实是整个计划的立场。维护者的项目，得维护者说了算。
第二，每一条发现送到维护者手上之前，先过一遍人类工程师。
这是最关键的一环，也是 OpenAI 自己毫不避讳承认的地方：前沿模型非常擅长找漏洞，但它们同时会产出大量误报。 直接把这些结果倒给维护者，只会让本来就爆掉的待办清单雪上加霜。
中间那道人工关卡要做的是：复现证据、对照项目文档和威胁模型检查、去重、重新定级、按优先级排序，最后按维护者的偏好把补丁写好一起提交。
这一步的附加价值，怎么强调都不为过。最后打什么补丁、怎么披露，始终由维护者说了算。 计划不会替项目做决定，也不要求项目按它的方式来。
第三，连补丁一起做，不只是报个信。
「修补地球」的研究人员从验证一直做到写补丁、测试、然后按项目自己的渠道做披露，交付的是能直接使用的东西，不是一个待办事项。
第四，把一次性的活做成可复用的工具。
参与的项目能拿到 ChatGPT Pro、Codex Security 的准入资格，以及用于核心开发、维护者自动化和发布流程的 API 额度。
另外，遇到 PHP 这次这种级别的漏洞，OpenAI 还准备了一套五阶段的协调响应框架：
- 先由维护者和研究者把上游漏洞验证并修复掉，这一步里包括用模型做对抗性测试，专门去找绕开补丁的方法和同类变体。
- 判断哪些组织需要提前知道消息，好去准备防护措施，具体邀请谁由维护者决定。
- 跟政府那边协调，把安全指导传达给负责关键基础设施的单位。
- 等修复、指导材料和披露计划都稳了，再拉更多发行方、托管商和运维人员进来准备更新。
- 补丁可用之后公开发布指导，并继续支持部署。
PHP 这次就是照着这套走的。提前拿到补丁的发行版有整整一天时间打包，Cloudflare 这类厂商提前备好了 WAF 规则，白宫超级智能工作组、ONCD 和 CISA 也都收到了通知。
这套框架里有两个细节值得单独说。
一是信息是分级发的。每个参与方拿到的东西不一样，最轻的是带失陷指标（IOC）的网络日志，最重的是能真正跑起来的漏洞利用程序。OpenAI 自己也承认，哪怕只是有限的细节都可能暴露漏洞，所以每多给一份都要掂量风险和收益。
二是时间点可以推翻重来。如果出现这四种情况之一，就要重新评估披露时间：漏洞已经在被实际利用、信息泄露了、公开补丁把漏洞暴露了、修复卡住不动导致用户风险上升。
PHP 这次正好撞上第二种，所以发布时间从原定的 10 月 22 日提前到了 10 月 21 日。
现在已经做出什么了
分两块看，一块是基础设施，一块是实打实的战绩。
先看基础设施。
Trail of Bits 派了专职安全工程师，用 Codex 和 GPT-5.5-Cyber 在 19 个开源项目上全职跑了一轮，结果是发现了数百个安全问题，合并了数十个补丁，还有一大批在走协调披露流程。
但比这些数字更有价值的是，这一轮顺手做出了四套能一直用下去的东西：
- 一天搭起来的模糊测试（fuzzing）实验室。
工程师只负责定目标和调提示词，系统靠覆盖率反馈自己往新的代码面扩，最后覆盖几十个入口、多种构建变体、多个平台和一批新种子。整套不到一天。Trail of Bits 自己估：人工搭同样一个，至少得好几周。 - 一条找"已知漏洞变体"的流水线。
吃进历史上的 CVE，抽出漏洞模式，再拿这个模式去扫目标代码库，候选结果交给专门的判定 agent 过一遍。流程上设了四道关：先判断这个 CVE 有没有变体可找，然后连着两道误报判定，再查重，最后一道报告门。四种结局：跳过、当误报扔掉、当重复扔掉、确认是个新的非重复问题。用他们的话说，这等于把公开的漏洞历史变成了一套可重复使用的搜索策略。 - 差分测试（differential testing）从几个月压到几天。
同一个协议的多个实现，用同样的输入跑，行为要是不一致，里面多半有 bug。难的是给每个实现写适配层，这部分 Codex 自己生成和迭代。原来几周几个月的工作，现在几天出结果。 - 照着规范去测。
基于项目的规格文档和 RFC 生成威胁模型、攻击分类、不变式测试和属性测试，找出"声称的行为"和"实际的行为"之间的差距。
这四样东西都留给了项目方，下次再出事就不需要从头来一遍。
再看战绩。
这一串是 OpenAI 公开的部分，涉及的项目都已经在走披露或者已经修完：
| 目标 | 做到了什么 |
|---|---|
| Linux 内核 | 在 3000 多万行代码里定位安全相关组件，动态验证后生成 8 个内核指针信息泄露的 PoC、24 个本地提权 exploit。发现的漏洞有数百个，这只是自动生成了 PoC 的那部分 |
| OpenBSD | 挖出一个 23 年的释放后重用（UAF），在 System V 信号量的内核实现里，普通本地用户能提权到 root |
| FreeBSD | 确认 34 个漏洞，产出 7 个本地提权 PoC |
| dnsmasq | 后来在 2.92rel2 里修掉的六个 CVE，有四个是它独立先找到对应模式的 |
| HTTP/2 Bomb | 一个影响 NGINX、Apache、IIS、Pingora 的拒绝服务手法，据估算有 88 万多个对外网站跑着受影响的服务端软件并且开着 HTTP/2 |
| Chrome | 在 V8 引擎里找到并报告 5 个可利用漏洞，其中 3 个在代码引入几天内就被发现并修掉 |
| Safari | 集中搞了一周 WebKit，找出并报告 10 多个可利用漏洞 |
| Firefox | 在 Pwn2Own Berlin 前两天报了个 WebAssembly 漏洞（CVE-2026-8390），Mozilla 当天补上，结果六个报名的 Firefox 条目里有五个撤了，比赛上没有一个 Firefox 利用跑成 |
最后这条我觉得最有意思：AI 不只是抢在攻击者前面，它抢到了连攻击比赛都来不及反应。
PHP2Shell 属于同一批工作的成果，只是模型换了一个：Calif 用的是 GPT-5.6 Sol，Wiz 也独立发现并报告了，真正把补丁写出来、把版本发出去的是 PHP 的维护者。这个区分很重要，AI 那部分是把问题找出来并证明它能打，剩下的活还是人干的。
PHP2Shell 被定性是近年来影响最大的安全问题之一。他们有个说法挺贴切，叫「防御者窗口期」：据其所知，前沿 AI 比攻击者更早发现了这些漏洞，于是给维护者和安全厂商抢出一段时间去准备修复和防护。
这里要提醒一句，上面这些只是公开出来的那部分。还在走披露流程的、涉及具体利用手法的，都还压着没放。
接下来想干什么
钱和工具这一块，OpenAI 给的大致是这些：
- 价值 10 亿美元的 Daybreak 使用补贴，给的是承担关键防护职责但资源有限的一线防御者。这是使用额度，不是直接给开源项目的钱。
- 通过 Codex for OSS 给所有维护者提供订阅。
- 直接赞助 Rust 基金会这类项目。
- 参与项目能拿到 ChatGPT Pro、Codex Security 准入资格，以及用于核心开发、维护者自动化和发布流程的 API 额度。
- PHP 这次还顺手开源了一个检测工具，做成 Codex 技能的形式，帮运维人员查自己的 PHP 版本是不是有问题：
https://github.com/openai/php2shell-checker
再往后，OpenAI 想做的已经不只是"发现和修单个漏洞"，而是从源头上少出漏洞。他们列了四个方向：更安全的默认设置、把关键组件迁到内存安全的语言、形式化验证、更严的沙箱隔离。 最后一条说得很实在：系统总得防住那些还没被发现、或者还没修好的漏洞，把处理不可信文件的软件关进沙箱里跑，就算被拿下也能把损失圈住。
另外有一段我觉得挺值得看的，是他们自己的两难：为了防止滥用而加的拦截，也可能挡住正当的安全工作。 让更多人用上强模型，和把滥用挡住，两件事都重要，只能一边用一边调。
多说两句
这个计划最让我认同的一点，不是它展现了模型有多能挖洞，而是它默认了"模型会产出一堆垃圾"，所以必须在中间放一层人。
这个设计看着是在给 AI 打补丁，其实是在给维护者挡刀。开源世界真正的稀缺资源从来不是发现问题的算力，是那几个愿意为一个不是自己写的、也没有人付钱的项目负责到底的人。
AI 把"找到问题"这件事做到了白菜价，接下来所有压力都会堆到"修好问题"这一头。谁先把这一头的能力补上，谁才算真的让互联网更安全了一点。
至于能补到什么程度，现在还早。这个计划自己说的也是：随着更多修复落地、更多协调披露走完，才会发布更深入的技术报告。
OpenAI 在计划页最后写了句话，我觉得是整件事最好的注脚：开源软件是共享的基础设施，那么保护它就该是共享的工作。
