PHP老Bug被AI挖成RCE漏洞：全球七成网站受影响

有个普通Bug在程序员的待办清单里躺了两年没人碰，听着好像算不上什么大事。哪个软件项目没攒着一堆暂时修不完的小毛病？只要不影响正常使用，不少Bug最后就这么被忘掉了。

可这回的情形不太一样。

2024年就被发现的一个PHP内存错误，起初只被当成会让程序崩掉的问题。谁也没料到，今年安全研究人员借着AI工具，从里面摸出了一条攻击路径：黑客能靠它在服务器上执行任意代码，甚至把服务器直接拿下。

麻烦在于，牵涉到的并非什么冷门项目。NASA、维基百科、白宫等网站，还有大批用WordPress、Drupal等技术搭起来的站点，都可能被波及——这就是前不久在网络安全圈引发关注的PHP2Shell漏洞。

围绕这起事件，网络安全初创公司Tolmo的AI安全研究负责人Matt Suiche给出了这样的判断：

“过去40年里由人类编写的所有遗留软件，其潜藏的Bug正在逐渐暴露出来。现在，是时候偿还这些技术债了。”

两年前没人当回事的Bug，如今能让黑客控制服务器

先说说PHP2Shell是什么。PHP诞生于1994年，最初是Personal Home Page（个人主页）的缩写。

新语言、新框架眼下层出不穷，可PHP照样撑着大量互联网网站运转，WordPress、Drupal这些常见网站系统都离不开它——W3Techs的网站技术统计显示，PHP仍是广泛使用的服务器端脚本语言，全球约七成网站业务靠它支撑。

这次的Bug，恰恰出在PHP自身的底层代码里。

2024年，研究人员就向PHP基金会报告过一个跟内存不足（Out-of-Memory，OOM）有关的Bug。说白了，就是程序给某段数据分配的内存空间不够用。这类错误一般会让程序崩溃，影响正常运行，但看上去不会直接威胁系统安全。

于是这个Bug一直没被当回事。直到今年7月，在OpenAI发起的Patch the Planet安全计划支持下，网络安全公司Calif对PHP做了一次独立安全审计。

研究人员Ryan Austin用AI工具，只花了几天，就找到了这个内存错误背后的另一种可能：攻击者能利用程序处理异常时留下的问题，进一步操纵内存，最终实现远程代码执行（RCE）。

事情的性质就此变了：原来只会让程序崩溃的Bug，现在可能变成攻击者进入服务器的入口；一旦利用成功，攻击者就能执行恶意代码、读取敏感数据，甚至装上恶意软件。

之后Calif又找到了其他可利用路径，并把问题报告给PHP基金会。网络安全公司Wiz和OpenAI也参与了后续验证与分析。这些问题最终被归纳为PHP2Shell，涉及两个严重的远程代码执行漏洞：CVE-2026-109618和CVE-2026-109619。

Wiz还在WordPress、Drupal和Joomla等常见网站应用上做了验证，发现攻击者甚至可能无需身份验证就能发动攻击。换句话说，问题不在某个网站配置不当，而是PHP底层运行环境本身就有安全隐患。

AI究竟做了什么？把专家都嫌麻烦的活儿干了

一个问题随之而来：这个Bug存在两年了，此前为什么没人把它挖成严重漏洞，AI却能在短时间内找到突破口？

哥伦比亚大学计算机科学副教授Suman Jana的解释挺有意思：这个Bug并不神秘，难的是利用它需要做大量非常具体、非常繁琐的推理。

要真正利用内存错误，研究人员得摸清目标程序的内存布局，找到可以跳转的位置，再算出按什么顺序覆盖哪些数据，才能最终控制系统——这就像发现一扇门没锁，不等于你马上就能进屋，你还得搞清楚门在哪里、怎么打开，进去之后又该怎么行动。

Suman Jana认为，AI在这种需要反复分析和推理的任务上表现得相当出色。他说，这算不上什么高深莫测的技术，只是需要大量令人头疼的细节分析，而AI恰好能把这些工作处理好。

当然，他也强调，不能把这次成果简单归功于AI独立完成了漏洞挖掘：Calif、OpenAI和Wiz的研究人员本身都有丰富的网络安全知识和PHP技术背景，AI更多是当辅助工具，帮他们更快完成分析。

效率上的变化已经相当明显。Suman Jana表示，原本只有最顶尖的0.1%专家才能完成的工作，现在借助AI，他们能挖出更多问题；那些离顶尖水平还有差距的研究人员，也有机会借助AI参与更复杂的安全研究，不必事事都从底层细节开始摸索。

不过，这种能力也意味着，未来Bug被发现和利用的门槛可能进一步降低。

找漏洞只要几天，补漏洞却拖了两个月

漏洞被发现只花了几天，可修复远没这么轻松。PHP 基金会接到报告后，拉来 4 名工程师，前后投入两个月，相关补丁的开发和测试才告完成。

Suman Jana 说得直白：找 Bug 和修 Bug 天生不对等。找，只要找到一条能突破系统防线的入口就够了；修，却得把所有相关攻击路径逐一堵死，软件原有的功能还不能受影响。

PHP 这样的开源项目，维护压力尤其大。

不少开源软件被全球大量企业和网站依赖，背后却没有稳定的商业收入。维护者只能在有限的人手和资金下，长期扛起安全审计、Bug 修复和版本维护。现在 AI 又把挖 Bug 的成本压得更低：攻击者用更短时间就能找到更多 Bug，维护者却没法凭空变出人手。

对此 Jana 给出一个建议：防守方也该拿到更多资源，让他们能用上最先进的 AI 模型。

眼下，一些前沿 AI 实验室已经开始向安全研究人员发放 Token 额度，帮他们寻找和分析 Bug。Jana 认为这种支持还应继续扩大，行业联合行动也好，直接捐赠资金和算力也好，都值得鼓励。

总不能攻击者手里握着更先进的 AI 工具，防守方还只能靠人力硬扛。点点排查。

专家担心：真正严重的事故，可能还没来

AI 能不能彻底改变软件安全维护的现状？业内专家并没有形成一致意见。约翰斯·霍普金斯大学计算机科学副教授 Matthew Green 就判断，在真正严重的安全事故出现之前，很多机构恐怕不会主动拿出足够资源去处理这些问题。

在他看来，这次的 PHP2Shell 还没严重到让所有人都警醒的地步。他甚至预测，2027 年初可能出现一次波及普通人的重大安全事件，到那时企业和相关机构才会真正开始大规模掏钱。

对普通用户来说，眼下能做的其实很简单：及时更新软件。Matthew Green 特别提醒，手机或电脑一旦弹出安全更新提示，别想着下周再装，尽快更新完事。

PHP2Shell 后来的走势也说明，这次并非虚惊一场。AWS 的安全蜜罐系统在10月17日捕获了相关Bug的攻击尝试；10月26日，CISA 又将两个 PHP2Shell 漏洞列入已知遭利用的漏洞目录。

目前 PHP 已发布修复版本，包括 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。还在用受影响版本的网站管理员和开发者，升级已是当务之急。

HN 网友热议：AI 是在帮我们还“技术债”，还是制造更多麻烦？

说到底，PHP2Shell 让人不安的地方，不只是一个老 Bug 突然变成致命漏洞，而是它揭开了一个现实：过去几十年攒下来的代码，可能远没有我们以为的那么安全。

而且，这次被翻出来的是 PHP，下一次又会轮到谁？

“AI 正在逼我们还清 40 年的技术债”——这个说法最近在 Hacker News（HN）上吵翻了。到发稿时，这则讨论已经拿到 1305 个赞、749 条评论。不少开发者围绕同一个问题争论不休：

如果 AI 能把过去几十年遗留代码里的 Bug 一个个挖出来，软件行业究竟是迎来安全新时代，还是要陷入一场永无止境的修 Bug 大战？

也有人挺乐观。一位网友的看法是，AI 大范围挖漏洞，说不定顺手就能翻出过去被国家级组织、商业间谍公司有意藏起来的后门和零日漏洞（0-day）。他的原话是：“短期内，开发者可能要面对一大堆新披露的 CVE 和补丁，日子不会太好过；但从长远来看，软件生态反而会变得更加安全。”

也有人觉得，既然 AI 未来可能发现几乎所有 Bug，那唯一合理的目标就是做出真正无缺陷的软件：靠 AI 和形式化验证，让代码的正确性能够被严格证明，或许才是最终出路。

不过质疑声也不少——有开发者抛出一个很现实的问题：每多一行代码，都可能变成新的“技术债”。

人类会在“加这行”和“不做这个功能”之间痛苦权衡，AI 不会，它倾向于把东西都加上去。以近期的 Brotli 漏洞为例：一个实际上很少有人真正需要、甚至没被业务使用的组件，却因为被广泛打包进各种软件和系统，最终让大量环境暴露在攻击风险之下——从 IIS 到 Caddy，都可能受影响。

更有网友问得尖锐：AI 究竟是在帮我们偿还“技术债”，还是把我们推进了一条永无止境的修 Bug 生产线？不是所有技术债都能靠一个小补丁解决，很多问题牵涉系统架构调整，甚至要重新开发。

AI 就算能一直找出问题、修好问题，每次动大一点的代码，也可能带出新的 Bug。说到底，如果 AI 始终没法一次就生成真正靠得住的软件，开发者就只能在「发现 Bug—修复 Bug—出现 Bug—继续修复」这条线上来回打转。

这场讨论，眼下显然还没有答案。

不过有件事值得认真想一想：AI 轻松生成数千行代码的当下，哪些代码真有必要存在，是不是更该慎重决定？AI 让写代码越来越便宜，可代码背后的维护成本和安全责任，并不会跟着一起消失。

参考链接：

https://spectrum.ieee.org/ai-in-cybersecurity-php2shell-vulnerability

https://news.ycombinator.com/item?id=50364336