PHP2Shell 只是开始：AI 正在加速漏洞补丁竞赛

本周，欧洲各地的政府网站和公共服务相继下线，原因是各机构正在应对两个新披露的 PHP 漏洞。德国将多个联邦网站下线，法国暂时关闭了省级行政网站，比利时的外交部停用了其网站，荷兰的机构也出于预防考虑撤下了面向公众的服务。这一情况并不局限于欧洲，全球无数其他机构和企业的反应也如出一辙。

他们都在等待一个尚不存在的 PHP 漏洞缓解方案。

罪魁祸首是 PHP2Shell：CVE-2026-109618 和 CVE-2026-109619。尽管社区反应迅速，PHP 项目也在 10 月 21 日上午为所有社区支持的 PHP 版本发布了修复程序，但更大的问题仍未解决：据估计，40% 的 PHP 用户运行的是不受支持的 PHP，而与此同时，AI 已使 CVE 的发现速度呈指数级加快。

“本周发生的事情有所不同，而这只是开源生态系统中一场注定将持续下去的战役的第一枪。”

我投身开源贡献已超过 20 年；我领导 Laminas 项目，担任 Perforce Zend 和 OpenLogic 的首席产品经理，目前还在 PHP 基金会董事会任职——这一切都说明，我见过的新安全威胁远超常人。

本周发生的事情有所不同，而这只是开源生态系统中一场注定将持续下去的战役的第一枪。

关于 PHP2Shell，你需要了解什么

CVE-2026-109618 和 CVE-2026-109619 目前被称为 PHP2Shell，它们会带来远程代码执行（RCE）风险，触发条件是内存耗尽（OOM）状况与 PHP 错误处理的组合。从 5.4 起的每个 PHP 版本都至少受其中一个影响。这两个漏洞尤其令人担忧，因为它们存在于 PHP 本身，而非某个单独的应用、CMS 或框架中；除了打补丁的 PHP 运行时之外，没有真正可行的缓解措施。

Wiz Research 发现，这些漏洞可能让攻击者远程执行代码，或泄露进程内存中的敏感信息，包括密码、身份验证令牌、API 密钥和证书。这种泄露与运行在 PHP 上的应用无关。

此外，独立复现了这些漏洞的 Datadog Security Labs 发现，应用层身份验证无法阻止攻击，因为 PHP 会在应用代码运行之前就处理恶意请求。在复现 CVE-2026-109618 时，研究人员报告称，该请求“从未到达目标应用的代码”。

“即使有扎实的应用安全实践，你的应用仍可能暴露，因为存在漏洞的行为发生在应用之下，即 PHP 运行时本身。”

这意味着，即使有扎实的应用安全实践，你的应用仍可能暴露，因为存在漏洞的行为发生在应用之下，即 PHP 运行时本身。

解决办法就是打补丁。

社区齐心协力

今年 8 月，当完整影响变得清晰后，PHP 生态系统安全团队、PHP 基金会和各版本发布经理为所有受支持的 PHP 版本提供了修复程序。在一项跨生态系统的努力中，他们还与 LTS 厂商（如 Zend）合作，确保同时创建并发布所有补丁。

这是我 20 多年来第一次看到这样的努力，我赞赏社区朝这个方向迈进。得益于这一举措，任何使用社区不再支持的 PHP 版本（8.1 或更早）的人，都能在没有任何缺口的情况下，继续抵御这些新披露的 CVE。

遗憾的是，这种合作也依赖于信任，而信任在这里受到了考验。CVE 编号于 10 月 20 日泄露，导致所有发布提前了一天。但截至 10 月 21 日 14:00 UTC，所有社区支持的 PHP 版本都已获得缓解这些漏洞的更新。我在 Zend 的团队以及其他 LTS 提供商，也为 EOL PHP 版本发布了补丁。

虽然未来几周我们还需要更全面的措施，但这些缓解措施将在过渡期内，让支撑政府、医院、金融机构、学校等的关键应用保持安全并继续获得支持。

AI 正在改变漏洞研究的经济学

PHP2Shell 是一个典型例子，说明了当 AI 让困难的安全研究变得更易获取时会发生什么——以及随之而来的危险。

作为 OpenAI “Patch the Planet” 计划的一部分，Calif 使用 GPT-5.6 Sol 发现了一个严重的 PHP 漏洞。PHP 的维护者主导了修复和发布工作，研究人员和安全提供商在披露前贡献了测试、技术支持和协调。

“我们一直在与漏洞披露、补丁可用性和漏洞利用赛跑。PHP2Shell 表明，这场竞赛可能、也很可能会变得多么令人不安和艰难。

最引人注目的是规模上可能发生的变化。OpenAI 表示，这些已经是其发现并正在着手处理的若干重大漏洞之一，并预计类似的发现“在未来几个月内会急剧增加”。

我们一直在与漏洞披露、补丁可用性和漏洞利用赛跑。PHP2Shell 表明，这场竞赛可能、也很可能会变得多么令人不安和艰难。

还在运行 EOL 开源软件？AI 正在加大风险。

在 PHP2Shell 这样的漏洞出现后，最简单的建议就是立即升级。但实际操作起来要复杂得多。

PHP 8.1 及更早版本不再从 PHP 项目获得更新，尽管一些发行版和长期支持厂商会提供向后移植的安全修复。对于关键应用而言，迁移到新的运行时可能需要更新框架、库、扩展和应用代码，还需要进行测试以确保这些更改不会影响生产环境。

随着 AI 提升漏洞研究能力，这一差距会不断扩大，所以这不仅仅是 PHP 的问题。PHP 只是即将波及大多数主流开源技术的第一个重大案例。例如，过去几个月我们看到了大量 Spring 漏洞报告的涌现，而 Node.js 和 Python 也在 PHP2Shell 曝光的同一天报告了严重漏洞。我还必须提到 Linus Torvalds 最近的评论，他指出由于 AI 生成的漏洞报告，Linux 安全邮件列表正变得难以管理。

我在 Perforce Software 从事开源软件和 PHP 工作期间，逐渐将 LTS 视为通往现代化的桥梁。它让团队能够继续处理安全漏洞，同时规划、测试并执行向受支持版本的迁移。而且，随着漏洞发现速度加快，无限期地停留在不受支持的软件上会越来越难以自圆其说。

组织需要在力所能及的地方保持更新，并为无法立即升级的系统制定深思熟虑的安全策略。漏洞被发现得越快，这一点就越重要。

接下来会发生什么？

对于 PHP 用户来说，当务之急很明确：迁移到已修复的版本，或者为原本不受支持的版本获取适当的安全修复。但让我们更长远地谈谈。

人们很容易把 PHP2Shell 当作 PHP 突然变得不安全的证据，但这与事实相去甚远。本周社区和厂商的共同努力证明了这一点。相反，我们需要改变对安全的看法，因为这类漏洞只会变得更加常见。

“是的，我们发现有难度的安全问题的能力提高了。但我们响应能力需要跟上步伐。”

AI 正在改变哪些安全调查变得可行以及它们能以多快的速度进行。当研究人员与项目及更广泛的生态系统合作解决漏洞时，这很有价值。但这也给组织带来了更大压力，要求它们了解自己运行的是什么、尽可能使用受支持的版本、建立清晰的漏洞响应流程，并为无法立即升级的应用制定计划。

是的，我们发现有难度的安全问题的能力提高了。但我们的响应能力需要跟上步伐。

文章《PHP2Shell 只是开始：AI 正在加速补丁竞赛》首发于 The New Stack。