AI找出PHP十年老漏洞，你的防线还挡得住更聪明的攻击者吗？

10月21日，PHP发布紧急修复，处理两个可让未认证攻击者远程执行代码的严重漏洞，影响范围被描述为"所有处理Web请求的PHP安装"。Wiz的估算被美联社引用：PHP驱动着约70%的网站。这个数字说的是PHP有多普遍，不是有多少站点被确认存在漏洞。参与发现漏洞的研究者用上了前沿AI模型，BBC新闻等媒体都报道了这件事。

这件事引出的问题比一个补丁大得多：当AI系统读代码的能力可能很快超过我们，那些由人写下的代码该怎么保安全？一个务实的回答是，我们没法让所有代码都没有漏洞，所以该换一个问题——对每一道防线都问一句：如果攻击者比团队里所有人都聪明，它还管用吗？

PHP2Shell特殊在哪

这批漏洞的绰号是PHP2Shell，它们出在PHP本身，而不是建在PHP之上的应用里。Wiz的说法是，"过去十年发布的每一个PHP版本都至少受其中一个漏洞影响"，并且"即便是一个跑在受影响版本上的简单Hello World应用也可能中招"。加拿大网络安全中心把两个漏洞都归类为释放后使用（use-after-free）缺陷，属于经典的内存安全错误。

功劳是共享的。Wiz用自家Atlas工具配合谷歌的Gemini 4 Argon和OpenAI的GPT-5.6 Sol；OpenAI称安全公司Calif用GPT-5.6 Sol发现了一个严重漏洞；PHP基金会则表示，其签约的一位核心开发者在修复2024年审计遗留问题时，最先看到了问题的迹象。

Wiz报告里有个细节值得反复看：利用这些漏洞需要"一条异常复杂的步骤链"，而"前沿AI模型大幅降低了这道门槛，把一个长期存在的缺陷变成了可用的攻击手段"。Wiz进一步写道："复杂性可能不再构成有意义的屏障。"十年来保护这些服务器的，不是漏洞不存在，而是用起来太难。

现有证据并不显示有AI代理自行发现并武器化这些漏洞，它显示的是熟练团队把模型和自己的工具、经验放在一起用。但这已经足够说明问题：AI辅助的漏洞研究能降低把难利用的漏洞变成实际攻击所需的专业门槛和投入。任何依赖"这事太难没人做"的防线，都因此被动摇。

更聪明攻击者测试

有些控制手段之所以有效，是因为攻击者时间、技术或耐心有限：隐蔽性、复杂性、模式匹配过滤器，以及"没人会费这个劲"的假设。另一些手段改变的是攻击的条件：消除一整类缺陷、证明特定性质、让代码不可达、限制一次成功利用能拿到什么。它们的保护不建立在攻击者耗尽技术或耐心之上。不过它们强度并不相同，各有各的局限。

Cloudflare的应对展示了前一类手段的运作方式：在披露前约九小时部署防火墙规则，随后"观察攻击者如何变异攻击载荷以试图绕过我们的防护"。Cloudflare仍建议客户打补丁，称这些规则是"额外的纵深防御层"。匹配已知模式的过滤器能争取时间，但有能力的攻击者会变换模式。

更站得住的五道防线及其局限

• 消除缺陷类别。最有力的证据来自安卓。谷歌报告称，团队开始"将新开发转向内存安全语言"后，内存安全问题占安卓漏洞的比例从2019年的76%降到2024年的24%。其结论对"所有人类写的代码"这个问题很关键："我们不需要丢弃或重写所有现存的内存不安全代码"，因为"代码会随时间成熟并变得更安全"。内存安全消除的是特定类别的缺陷，主要作用于新代码，逻辑漏洞依然存在。
• 证明最关键的部分。证明不在乎攻击者有多聪明。seL4内核拥有"从高层规格到二进制代码的机器校验数学证明"。局限在措辞里：证明覆盖的是你指定的性质、在你声明的假设之下，seL4把汇编代码、启动代码和硬件都列为假设。证明也可能数学上正确，而规格漏掉了系统真正需要的安全性质。
• 缩小可达面。攻击者无法通过某条攻击路径触达的代码，就无法经该路径被利用，无论他多聪明。10月20日，Anthropic描述了用Claude跑过25个以上开源项目、发现493个此类问题的过程。在OpenSSH中，约4500行后量子签名代码占了"默认sshd中OpenSSH自身预认证代码的约16%"，维护者在10.6版本中发布了改动。Anthropic明确表示这不会消除未知漏洞，只是让它们"更难被触达"。
• 隔离你修不了的部分。补丁延迟时，加拿大网络安全中心建议机构"考虑在修复可用前，将面向互联网的应用与公共网络隔离"。同样的思路可以长期适用：用所需的最小权限运行处理不可信输入的代码，让一次成功利用拿不到多少东西。但隔离不是预防，被攻陷的进程仍能在其权限范围内造成损害。
• 缩短窗口。据PHP基金会，披露"在目标发布日前两天之前一直运作良好"，随后细节泄露。公告之后，据美联社，Cloudflare的马修·普林斯称数小时内出现了"数百万"次利用尝试。补丁并非完全独立于攻击者的能力，更快的攻击者仍可能赢下通往未打补丁服务器的竞赛。缩短窗口做的是减少机会。

瓶颈在验证，不在发现

OpenAI称"前沿AI在攻击者之前发现了这些漏洞"，并预计"类似发现将在未来几个月大幅增加"。这是乐观版本：防御方先用上同样的模型。PHP基金会的说法展示了代价：团队"处理了100多份最终被判定为无效、重复或无法复现的报告"，"每个判断、每个补丁都由人来完成"，而工作"仍依赖一小群基金会资助的开发者和少量志愿帮助"。

如果AI让发现候选漏洞变得便宜，稀缺技能就变成判断哪些发现是真的、复现它们、确认修复有效。这是一项带误报率、复现标准和审查队列的评估工作，需要人和资金，和需要模型一样多。拆开看，工作是这样的：

1. 分诊：报告是否新、在范围内、与安全相关？
2. 复现：独立审查者能否可靠触发该故障？
3. 评估：哪些配置受影响，攻击需要什么条件，影响是什么？
4. 修复：补丁是否消除了底层缺陷且未引入回归？
5. 验证：回归测试是否在修复前失败、修复后通过？

更多发现并不自动等于更安全。发现制造工作量，验证和修复才把它变成更低的风险。

给团队的五道自检题

加拿大网络安全中心的建议是个不错的优先顺序："优先处理面向互联网、处理不可信输入的系统和应用。"其公告还指出，PHP 8.1及更早版本不再从PHP项目获得安全更新，仍停留在这些版本上的机构可能需要厂商提供的向后移植或迁移方案，而不是常规的上游更新。对工作团队来说，可以把测试变成五个问题：

• 我们是否知道每一个对外暴露的运行时，以及由谁打补丁？仅更新网站代码或插件并不能修复PHP2Shell。
• 从公告到验证修复，一个关键运行时补丁要花我们多久？
• 部署了不等于修好了：被遗忘的实例、旧容器镜像、预发服务器或捆绑的运行时，都可能在主服务器打补丁后仍然脆弱。
• 解析不可信输入的新代码，是否用内存安全语言写？
• 有哪些可达代码是我们能关掉的？如果一个服务明天被攻陷，它能触达什么？

还没想清楚的地方

防御方的时间优势能否持续，目前没有答案。这次它被一次泄露缩短了，而且发现过程既有模型也有熟练的人类团队。重写和证明都慢且贵，所以大多数人类写的代码会保持原样多年，分诊才是现实方案而非全面覆盖。未来几个月里利用行为跟随披露的速度数据，以及AI生成漏洞报告的实测误报率，会让这个判断更清晰或发生改变。

没法靠抢先找出每一个漏洞，来让所有人类写的代码抵御一个聪明得多的攻击者。当发现漏洞的成本下降，我们需要的是不那么依赖"攻击者找不到"的系统：内存安全的新代码、最关键部分的证明、更小的可达面、真正的隔离、快速且经过验证的补丁，以及足够的人类审查者去确认模型发现了什么。

如果攻击者比你整个团队都聪明，你哪一道防线会最先失效？