AI 发现潜伏 14 年的 PHP 漏洞

AI 发现潜伏 14 年的 PHP 漏洞：老旧系统的安全启示

一个带 #php2shell 标签的故事正在程序员社区流传：AI 工具在审查旧代码时，发现了一个悄无声息存在了 14 年的 PHP 漏洞——这类漏洞可让攻击者在服务器上执行命令，把网站变成后门。值得深思的不是 AI 有多“聪明”，而是一个严重漏洞为何能在数百次维护、数千个运行日中无人察觉地潜伏下来。

发生了什么？

据流传的分享，有人用 AI 重新阅读一套老 PHP 系统的源代码时，发现一段代码允许用户输入直接进入系统命令执行函数——这是导致所谓“PHP to shell”的经典错误模式：从一个 Web 漏洞入手，攻击者可以在服务器上执行命令、安装网页后门（webshell），进而控制整台服务器。

最令人印象深刻的是：这个漏洞已经存在 14 年。它熬过了一个个版本、一任任维护者、一次次代码“大扫除”，却从未被发现——原因很简单，从来没有人真正带着找安全漏洞的眼光去重读旧代码。

漏洞为何能“冬眠”14 年？

这种现象并不罕见，背后的原因也相当普遍：

旧代码无人阅读。 编写者早已离开，文档不复存在，继任者只修报错的地方，其余部分绝不去碰——遵循“能跑就别动”的原则。
测试覆盖不到出错路径。 测试用例通常只确认主功能正常，而那些极少被走到的分支——恰恰是漏洞常藏身之处——却无人检验。
传统扫描工具漏报。 基于既有规则集的静态扫描器擅长捕捉常见错误模式，但面对复杂逻辑、跨多层数据传递的场景，它们往往要么沉默，要么报出多到让人无法筛选的噪音。
没有事故可供识别。 只要尚未被利用，漏洞就不会有任何外在表现。“系统一直跑得好好的”反倒成了它安全的错误证据。

PHP 遗留系统：越南众多企业的隐忧

PHP 仍然是越南大量网站、信息门户、内部管理系统的基础——从多年前搭建的企业官网到自发开发的内部门户。不少系统仍运行在已结束安全支持生命周期的 PHP 版本上（例如 PHP 7.x 分支自 2022 年底起不再接收补丁），遗留源码更无人敢升级。

遗留系统的双重风险在于：过时的底层不再获得厂商补丁，而自行编写的业务代码从未经过系统的安全审查。一旦被发现并利用，损失往往蔓延到客户数据和企业声誉。

AI 改变了我们审查旧代码的方式

这个故事所揭示的新变化是：“通读全部旧代码”的成本因 AI 而大幅下降。让一位工程师花几周去读数万行没有文档的代码非常困难；但 AI 可以扫描整个代码库，描述数据流向，指出用户输入通向敏感函数的位置，并解释为什么危险——然后由人类逐条核实警报。

必须说清局限：AI 会漏报，也会误报。它不能取代专业安全流程，而是第一道筛网，帮助技术团队把精力集中在风险最高的位置。自动扫描、安全测试与有重点的人工审查相结合，仍然是标准做法。

给企业的实操教训

即使你的系统不是用 PHP 写的，这些原则同样适用：

建立代码资产清单： 哪些系统在运行、用什么写的、谁负责、上一次安全审查是什么时候。
升级失去支持的底层平台： 运行在不再接收补丁的语言/操作系统版本上，等于把自己放在了保护范围之外。
落实最小权限原则（Principle of Least Privilege）： Web 进程只应拥有必需的最小权限，这样即使漏洞被利用，损失也被限制在一个局部。
把自动审查纳入流程： 静态扫描和 AI 审查应定期跑遍全部代码库，包括那些“稳定运行多年”的部分——因为那正是最少有目光投向的地方。
有计划地偿还技术债： 不必立刻全部重写，但要有分阶段的路线图，优先处理直接暴露在互联网上的模块。
盯紧日志与异常： 长期潜伏的网页后门通常会在访问日志里留下痕迹——前提是有人去读。