AI 辅助发现 PHP 底层高危漏洞

一段业务代码没改，网站却可能需要紧急下线。原文借一组被称为 PHP2Shell 的 PHP 漏洞，讨论 AI 如何改变安全研究：它可能让长期藏在底层运行时里的缺陷，更快变成可利用的攻击入口。

对程序员更有用的结论是：应用代码干净，不代表整个服务安全。不过，原文涉及的漏洞编号、模型名称、修复版本和停站事件，以下均按作者提供的信息解读，未作独立核验，不能直接作为生产环境的处置依据。

为什么业务没写错，也可能需要停站

原文给出的两个漏洞编号是 CVE-2026-109618 和 CVE-2026-109619，合称 PHP2Shell，CVSS v4.0 评分均为 9.2，属于严重级别。

问题出在 PHP 处理致命错误后的清理过程，尤其是内存不足错误。按照文中的解释，一次请求崩溃后，内部状态没有清理干净，后续请求可能继续使用这些残留状态。

大白话解释：前一个请求留下了失效的数据，后一个请求却还把它当成有效数据使用。这里存在跨请求的影响，风险没有随着报错页面返回而结束。

作者转述 Wiz 的研究称，研究人员在当时最新的 WordPress、Drupal 和 Joomla 容器镜像上，演示了无需身份认证的远程代码执行；另一种利用结果是读取服务器内存中的密码、令牌和 API keys，而不必先取得服务器控制权。

漏洞位于运行时，业务层的正确性覆盖不了这部分风险。

原文称，过去十年的 PHP 版本至少受到其中一个漏洞影响，范围可追溯到 PHP 5.4。但它没有展开不同漏洞对应的版本范围，也没有列出完整的部署条件。因此，「使用 PHP」和「当前部署可以被直接利用」之间，还缺少需要逐项确认的信息。

同样，标题中的「约 70% 的 Web」是对 PHP 使用范围的描述，不能直接当成可被攻击网站的比例。

AI 加速了发现，但没有替代漏洞验证

原文最吸引人的说法，来自 Wiz 研究人员：一名研究者配合前沿模型，用一周完成了过去可能需要顶尖团队数月才能完成的工作。涉及的工具是 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol。

这里需要拆开看两件事。

第一件是研究结果。按原文描述，他们找到了缺陷，并在具体应用环境中验证了远程代码执行和内存读取。另有 Calif 的 Ryan Austin，在 OpenAI 的「Patch the Planet」项目中审计 PHP 时，独立发现了同类问题。

第二件是效率评价。「一人一周」对比「团队数月」，是研究人员对工作量的判断。原文没有提供同一任务下的人类团队对照，也没有交代模型调用成本、失败尝试，以及人工筛选和验证各占多少时间。

因此，它支持「AI 已经参与复杂漏洞研究」，但不足以给一般团队算出一个可复用的提效倍数。

原文用下面这段时间线串起发现、验证、通报和修复，能看出找到漏洞距离完成处置还有多远：

timeline
    title PHP2Shell, from discovery to patch (2026)
    19 Aug : Wiz finds the first flaw with AI assistance
    20-21 Aug : Remote code execution confirmed on Drupal, then WordPress
    24 Aug : Flaws reported to the PHP security team
    21 Sep : PHP acknowledges and starts a coordinated fix
    20 Oct : PHP announces a critical release for the next day
    21 Oct : Patches ship at 14:00 UTC, NSA issues guidance, sites go offline

要留意最后一行：补丁发布发生在 2026 年 10 月 21 日 14:00 UTC。从 8 月发现问题到补丁落地，中间还涉及报告、确认和协调修复。模型缩短研究时间，并不会自动消除这些工程环节。

作者还提到，Google 的 Big Sleep 在 2024 年发现过 SQLite 中可利用的内存安全漏洞，开发者当天修复，问题没有进入正式版本。两者的关键差别在于暴露面：一个在发布前被截住，另一个据称已经存在十多年，且技术细节在预定披露前泄露。

真正吃紧的是补丁抵达服务器的速度

按原文记录，PHP 在 10 月 20 日提前宣布次日发布关键修复，并表示如果细节公开，可能提前发布。文中列出的修复版本是 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35；同时称 PHP 8.1 及更早版本已不再获得常规安全更新。

这组信息暴露出一个现实问题：发布补丁和所有用户装上补丁，是两件事。

应用维护者还依赖容器镜像、发行版软件包、托管平台和部署流程。遗留 WordPress 站点、无人维护的后台，即使访问量不大，也可能长期留在旧版本上。

原文称，NSA 建议无法及时更新的组织，在完成缓解前将受影响系统下线。法国、丹麦、芬兰、荷兰及加拿大的一些政府网站因此暂停服务，荷兰的 DigiD 也受到影响。这些是预防性停站，原文没有据此证明网站已经遭到入侵。

对用户而言，维护页面很显眼，内存泄露却可能很安静。按研究描述，密码和会话令牌可能被读取，而且未必留下明显痕迹。恢复页面访问，并不能单独证明风险已经处理完毕。

作者也记录了补丁背后的协作：Google Cloud、Cloudflare、AWS、Microsoft、Fastly、Akamai、Vercel 等参与准备防护；维护者 Remi 则完成软件包签名和发布。防护能否及时抵达用户，最终仍依赖这些具体的人和分发渠道。

我的判断

我认同作者把重点放在共享基础设施上。一个业务团队可以认真审查自己的代码，却仍然依赖运行时、系统库和软件仓库的维护质量。AI 若能帮助研究人员更早发现深层缺陷，价值很明确。

但「AI 让旧漏洞变得可利用」需要更谨慎。原文没有证明这些漏洞过去无法被人类发现或利用，也没有证明攻击者此前从未利用过它们。更稳妥的判断是：新的研究工具可能降低发现、分析和验证某些漏洞的成本。

漏洞存在多久，与团队还有多少应对时间，是两个不同的问题。

和常规依赖扫描相比，这类研究更深入：扫描通常识别已知漏洞，研究则试图发现尚未登记的问题。两者互补，不能因为模型找到了新漏洞，就跳过版本盘点和补丁管理。

作者引用 Heartbleed 和 Log4Shell，想说明事故可以推动基础设施投入。文中称，2014 年 Heartbleed 后，Linux Foundation 发起 Core Infrastructure Initiative，资助了两名全职 OpenSSL 开发者；2021 年 12 月 9 日披露、严重性评分为 10 的 Log4Shell，曾促使魁北克预防性关闭近 4,000 个政府网站。此后，2022 年 1 月举行相关会议，至 5 月形成十点计划，预计两年投入 1.5 亿美元，已有约 3,000 万美元承诺资金。

这些例子支持「共享基础设施需要持续投入」，却不能证明每次事故都会带来足够投入。

文末又用 NIST 于 2024 年 8 月发布首批三项后量子密码标准，类比外部能力变化带来的风险，并延伸到卫星和月球基地的软件维护。这是作者的观点展开，不是 PHP 漏洞实验的直接结论。对多数 Web 团队，更值得先解决的是：是否知道哪些服务受影响，补丁能否及时部署，失败后能否恢复。

能拿来做什么

• 为自己维护的站点建立运行时清单，记录 PHP 版本、容器基础镜像、软件包来源和维护负责人。前端团队若同时管理 WordPress 内容站或 PHP 接口，也要把它们纳入清单。
• 把补丁通告转换成可执行的升级流程：确认受影响条件，核对官方修复版本，更新部署产物，并验证线上实例实际使用的版本。原文中的版本号应先核验，再用于生产操作。
• 使用 AI 辅助审查时，把注意力放到错误处理和资源清理路径。让模型解释请求异常后哪些状态会保留，再由人工检查代码并验证判断，不把模型输出直接当作漏洞结论。
• 提前明确紧急下线和恢复的条件。对无法即时更新的服务，谁负责判断缓解措施、谁执行停站、恢复前检查什么，应当在事故发生前写清楚。