2024 年，PHP 核心开发者在处理一份外部安全审计的问题时，注意到另一个隐患：内存耗尽时，PHP 的收尾工作做得不干净。讨论下来，虽然有人怀疑它存在利用风险，却找不到具体的攻击路径。几种修复方案又各有代价，安全团队迟迟定不下来，问题就这样先放着了。
两年后，这个“先放着”的问题有了名字：PHP2Shell。
10 月 21 日，PHP 紧急发布 8.5.12、8.4.27、8.3.36 和 8.2.35，修复两个 CVSS 评分 9.2 的漏洞（CVE-2026-109618、CVE-2026-109619）。攻击者无需登录，就可能在服务器上执行任意代码，也就是典型的远程代码执行攻击。按 W3Techs 截至 11 月 9 日的统计，在能识别服务端语言的网站里，69.0% 用的是 PHP。
把它从“会崩溃”变成“能接管服务器”的，是一名安全研究员加上 AI，前后不到两周。
IEEE Spectrum 报道这件事时，给文章配的副标题是：AI 正在逼我们还清 40 年的技术债。这句话随后被原样搬上 Hacker News，引来七百多条评论。PHP 的这个老 Bug，只是其中一笔。
一个“只会崩溃”的 Bug
2024 年那次审计由 Quarkslab 执行，德国主权技术署出资。审计期间暴露的内存问题，当时没有找到具体的攻击路径，修复又面临兼容性、新的拒绝服务风险和大量扩展需要调整等取舍，因此被搁置。PHP 基金会事后复盘，把这次搁置称为“结构性失败”：安全团队决策流程不畅，人手也不够。
两个漏洞背后的内存管理问题并不难理解，真正构造出可用的攻击链却相当复杂。一个是内存耗尽时，PHP 会紧急跳出当前流程，留下只初始化了一半的内部数据，后续清理流程却把它当成正常数据处理；另一个是请求结束后，部分状态没有清干净，下一个请求能碰到已经释放的内存。至少一个漏洞可以追溯到 2012 年的 PHP 5.4。
麻烦在于位置。漏洞在 PHP 运行时本身，在 Apache 的 mod_php 部署下，其中一条利用路径甚至可以在网站代码执行之前触发。给 WordPress 插件打补丁、改业务代码，都挡不住。
哥伦比亚大学计算机系副教授 Suman Jana 对 IEEE Spectrum 解释，绝大多数崩溃类 Bug 都会被忽略，因为把崩溃变成利用，需要一长串细致的推理，而这恰好是 AI 擅长的事。
AI 做了什么，没做什么
今年 7 月 30 日，安全公司 Calif 在 OpenAI 资助下开始审计 PHP。研究员 Ryan Austin 借助 OpenAI 的模型，几天内就找到了按需触发内存耗尽的方法，并做出了针对 WordPress 的攻击。8 月 11 日，他向 PHP 团队报告了可用的远程代码执行；同一天，OpenAI 也独立报告了相同的根因。
8 月 19 日，云安全公司 Wiz 用自家平台 Wiz Atlas 加上 Gemini 4 Argon、GPT-5.6 Sol，又独立发现了这个问题，随后在 Drupal 和 WordPress 上验证了无需登录的接管。Calif 在自己的测试里，还打通了 MediaWiki 和 Nextcloud。
Wiz 联合创始人 Ami Luttwak 称，这是迄今 AI 协助发现的最严重漏洞。但 Austin 本人说得更克制：他没有用公众拿不到的模型，他挑的是自己有背景、熟悉其漏洞历史的目标，没有哪个模型靠简单的提示词就能挖出所有漏洞。
Jana 的看法类似：AI 单独做不成这件事，但能让顶尖专家做得多得多，也可能让不那么专业的人摸到漏洞利用的门槛。
Wiz 在技术报告里还提到一点：配合测试和调试工具，大模型能帮研究人员针对不同的 PHP 版本、配置和内存布局反复调整攻击链，分析失败的尝试，再一次次改进。也就是说，AI 改变的不只是找 Bug 的速度，还有利用 Bug 的成本。过去因为利用起来太麻烦而没人碰的老代码，现在未必还有这层保护。
补丁发布前，保密协议先破了
从 8 月报告到 10 月发布，PHP 的四名工程师花了两个月写修复，最终改动接近 200 个文件、一万多行代码。原定 10 月 22 日公开。
以下时间均为 UTC。10 月 20 日下午，漏洞编号先在网上泄露，还附带一个错误的 10.0 分评级。PHP 当晚发出预告，把发布提前一天。预告发出约半小时后，Calif 误发了一段演示视频，展示概念验证打通多个目标，副本很快在社交媒体上传开。第二天早上，Chainguard 又在正式发布前六个多小时上线了含修复的镜像，被 PHP 基金会批评为单方面打破保密约定。
欧洲多国政府先行“拔网线”。比利时外交部、德国联邦信息技术中心的部分网站下线；法国内政部应国家网络安全局要求，关闭了多个省政府网站；芬兰政府 IT 服务中心 Valtori 关停了部分服务。维基媒体基金会也暂停了一些系统。
发布时，PHP 基金会表示，流传的示例中还没有发现可用的漏洞利用。10 月 26 日，美国网络安全和基础设施安全局（CISA）把两个漏洞列入“已知被利用漏洞”目录。同一天，安全公司 Dream Research 披露了一起真实攻击：攻击者把 PHP2Shell 和一个 Linux 内核提权漏洞串起来，拿下了 25 台服务器。目标不是普通网站，而是 Palo Alto Networks 防火墙暴露在公网上的管理界面，它的后台跑的也是 PHP。10 月 29 日，Palo Alto 旗下的 Unit 42 确认，已独立验证攻击者的工具和结果。
Palo Alto 称，管理界面默认不对公网开放，受影响的设备约占全球装机量的 0.02%。Wiz 也表示，截至 10 月 27 日，自己的遥测数据里还没看到完整攻击链成功。目前仍没有证据表明 PHP 网站遭到大规模入侵，但这个漏洞已经不只是实验室里的演示了。
真正的长尾在旧版本。在使用 PHP 的网站中，25.8% 还在用 7.x，7.5% 在用 5.x。这些分支没有官方新版本，7.4、8.0 和 8.1 只拿到了需要自行编译的补丁，部分发行版和长期支持厂商则会自己回移修复。
谁来还这笔债
“40 年技术债”的说法，来自安全创业公司 Tolmo 的 Matt Suiche。他对 IEEE Spectrum 说，人类过去大约 40 年写下的遗留软件，正在被一层层暴露出来，现在到了偿还技术债的时候。
还债的难处在于不对称。Jana 指出，攻击者只要找到一条路，修复者却要堵住所有路，还不能破坏原有功能。PHP 基金会的数据也能说明压力：7 月以来，安全团队发布了 15 个 CVE，同时处理了一百多份无效、重复或无法复现的报告。基金会正在呼吁企业、托管商和政府出钱，多养几名工程师。
Jana 设想的解法是：一个模型写补丁，另一个模型写正确性证明，再用一个不依赖大模型的检查器来验证，因为大模型会产生幻觉。约翰斯·霍普金斯大学的 Matthew Green 则更悲观，他认为在出现更严重的事故之前，行业不太会真正加大投入，眼下能做的就是及时更新。
程序员们怎么看
Hacker News 上的评论，很快从 PHP 本身扯到了更大的问题。
有人顺着“技术债”往下推：既然 AI 能把所有 Bug 都翻出来，软件就得做到可证明正确，而这件事只有借助 AI 才可能实现。马上有人反驳：证明只能说明代码符合规格，规格本身也可能写错。还有人搬出 Knuth 那句老话，大意是“我只证明了代码正确，并没有运行过”。
也有人回到语言层面，认为指针运算、不检查边界的数组和释放后使用，本来就是内存不安全语言的设计问题；反方则说，内存安全挡不住逻辑错误和恶意但合法的输入。
另一条评论更直接：每一行代码都是负债，而大模型偏偏喜欢多写代码。
说回眼前。如果服务器上还跑着 PHP，先检查实际运行的版本，以及所用发行版是否已经发布安全修复。发行版回移修复时，版本号未必会变，所以只看版本号，既可能误以为没法修，也可能误以为已经安全。下一次被 AI 翻出来的旧账，未必还能给维护者留出两个月的准备时间。这类安全事件也提醒我们，开发者社区里的经验共享和情报互通，往往比单打独斗更能扛住突发风险——这也是云栈社区一直在做的事：让每个踩过坑的人都能把经验留下来。
主要参考来源
发表于 11 小时前
|
查看: 0|
回复: 0
/1 
