一个两年前就被报告过的 PHP 漏洞，原本只是一个普通的程序崩溃问题。
没人觉得它有多危险。
直到今年，一名安全研究人员借助 AI，只用了两周，就找到了利用这个漏洞控制服务器的方法。
这件事让整个漏洞的性质发生了变化：它不再是一个普通 Bug，而是一个可能让攻击者读取服务器敏感数据、执行恶意代码的严重安全漏洞。
而修复它，花了四名工程师两个月。
这件事引出了一个更大的问题：AI 是不是正在迫使软件行业偿还过去几十年积累的技术债？
我觉得，这比 PHP 本身出了什么漏洞更值得关注。
一个被忽略两年的 Bug
PHP 是一门诞生于 1994 年的编程语言。今天仍有大量网站运行在 PHP 之上，包括 WordPress、Drupal 等广泛使用的系统，它们支撑着互联网中相当大一部分基础设施。
这次出问题的，是 PHP 底层的一个内存错误。早在 2024 年，它就被报告给了 PHP 基金会，但当时表现出来的，只是程序可能因为内存分配问题而崩溃。
对于开发者来说，这类问题并不罕见。一个大型软件项目每天都可能收到大量 Bug 报告，其中有些只是程序崩溃，有些甚至很难稳定复现。资源有限，维护者必须决定先修什么。如果一个问题看起来只会导致程序崩溃，而不是让攻击者控制服务器，它自然很难排在最前面。
于是，这个 Bug 就留了下来。
直到今年，网络安全公司 Calif 在 OpenAI 资助的 PHP 安全审计项目中，重新检查了 PHP 的底层代码。借助 AI 工具，研究人员在两周内找到了一条此前没人注意到的攻击路径：利用这个内存错误，攻击者可以在服务器上执行任意代码。
原本看起来只是一次程序崩溃，背后藏着完全不同的安全风险。这就是 PHP2Shell 漏洞，受影响的代码最早可以追溯到 2012 年发布的 PHP 5.4。
AI 改变的，是发现漏洞的成本
AI 在这件事里起的作用，是降低了安全研究的门槛。
过去，挖掘一个复杂的底层漏洞，需要研究人员有相当深厚的专业知识。他们要理解程序如何分配内存，追踪不同函数之间的调用关系，判断数据在内存中的位置，还要反复测试不同的攻击路径。很多时候线索早就摆在那里，难的是顺着它一步步推下去，这要耗费大量时间。
AI 恰好擅长这类工作。它可以协助研究人员阅读庞大的代码库、梳理调用关系、提出可能的攻击路径，再通过测试逐个验证。
当然，这不意味着 AI 独立完成了整个漏洞研究。参与这次审计的研究人员本身就有深厚的网络安全和 PHP 背景，AI 更像一个能力放大器，让他们在更短的时间里尝试更多可能。哥伦比亚大学计算机科学副教授 Suman Jana 在接受 IEEE Spectrum 采访时也说，AI 正在帮顶尖安全专家完成更多工作，也让能力稍弱一些的研究人员，有机会处理过去需要更深底层知识的问题。
很多漏洞一直没人发现，是因为发现它要花的时间和专业成本太高。现在这个成本正在下降，能用上这些工具的也不只是防御方，攻击者一样可以。
找到漏洞，只是问题的开始
接下来发生的事，暴露了软件安全里一个老问题：发现漏洞和修复漏洞，难度根本不在一个量级。
找到一条可以利用的攻击路径，可能只需要证明在某个特殊条件下，攻击者能控制程序的执行。真正修复它，工程师却要确认所有相关的攻击路径都被堵住，同时原有功能不受影响。PHP 这样的成熟项目，底层代码运行了几十年，外部依赖和兼容性关系非常复杂，一个看起来简单的补丁，也可能影响大量现有应用。
IEEE Spectrum 报道称，PHP 团队收到漏洞报告后，安排了四名工程师，花了两个月开发补丁。研究人员借助 AI 两周找到的问题，维护者要两个月才能安全地修好。
PHP 只是一个例子。互联网上还有大量运行了十几年、几十年的软件，依赖着早已没人熟悉的代码和过时的组件，历史设计一层压着一层。很多问题开发者其实知道，只是没有足够的资源去处理。对商业公司来说，修复一个长期没被利用的旧漏洞，很难直接带来收入。开源项目的情况可能更糟：软件被全世界使用，真正负责维护的可能只有几个工程师，甚至要靠志愿者。
AI 可以帮他们发现问题，却不会替他们承担维护成本。
软件行业可能要面对一次安全债务清算
很多软件能长期运行，不一定是因为足够安全，也可能只是发现和利用漏洞的成本太高。
软件行业过去几十年的发展，优先考虑的往往是功能、速度和商业交付。只要系统还能正常运行，底层问题就会被一再推迟。内存管理、权限边界、依赖组件、历史兼容性，这些问题不会因为发布了新版本就自动消失，它们只是被留在了代码里。
现在 AI 降低了检查这些历史代码的成本，过去需要专业团队花几个月才能完成的安全研究，可能会变得越来越容易。未来我们大概会看到更多类似 PHP2Shell 的事件。AI 并没有让软件多出漏洞，只是让原本藏在代码深处的问题更容易被发现。
另一面也值得警惕：AI 一边帮我们清理旧代码，一边也在大量生成新代码。如果开发者只关心功能能不能跑通，却没有真正理解生成的代码，今天还掉的技术债，明天可能又以另一种形式欠回来。甚至可能出现一种荒诞的循环：AI 生成代码，AI 找到漏洞，AI 修复漏洞，最后又产生更多需要维护的代码。
所以，只让 AI 更擅长找 Bug 恐怕还不够。一些开发者在讨论用 Rust 这样的内存安全语言，从设计上减少一类底层漏洞。也有人在讨论形式化验证：让 AI 生成补丁的同时生成正确性证明，再交给独立的证明检查器验证。这些方法解决不了所有安全问题，但方向是一致的，就是不再把安全寄托在开发者足够细心，或者攻击者暂时没发现漏洞上。
最后，谁来为这些旧账买单？
这次 PHP2Shell 的结局相对幸运：研究人员先发现了问题，报告给了维护团队，PHP 团队也及时发布了补丁。
但下一次未必还能这么幸运。
AI 把发现漏洞的成本越压越低，软件行业就得面对一个问题：过去几十年积累的技术债，如果机器能越来越快地找出来，谁来负责修？
大型科技公司可以投入资金和算力，审计自己的核心代码。那些被全球广泛使用、却没有稳定收入的开源项目呢？它们是互联网基础设施的一部分，却未必承担得起一次大规模的安全审计。AI 让发现问题变得更容易，修复问题依然需要人、时间和资金。
过去，很多软件靠的是「暂时没人发现问题」。现在，这种侥幸越来越靠不住了。
AI 不一定会让软件行业变得更安全，但它正在让那些长期被忽略的不安全，越来越难以隐藏。
关于
关注我获取更多资讯
