PHP重大漏洞曝光：AI加速发现背后暴露的开源维护危机

你最喜欢的某个网站周三是否突然无法访问了？确实有一些网站下线了，运营方在等待修复方案时主动将服务下线。这里要修复的是PHP语言中的两个严重漏洞，而PHP正是支撑着互联网大部分网站运行的语言。

需要说明的是，这种预防性下线并不意味着这些网站已被攻破。漏洞本身的严重性毋庸置疑，但从长远来看，更值得关注的问题或许是补丁禁运期的处理方式本身。

PHP为全球约70%的网站提供支持，但这个数字描述的是PHP的使用覆盖面，并不代表存在漏洞或已遭入侵的网站数量。

WordPress已通知站点所有者更新PHP版本；需要说明的是，修复这些漏洞并不需要更新WordPress本身。

此次涉及的漏洞编号为CVE-2026-109618和CVE-2026-109619。PHP项目已发布修复版本8.2.35、8.3.36、8.4.27和8.5.12；使用旧版本分支的用户需要升级到官方支持的版本，或等待分发商提供的后向移植补丁。

此次被称为”PHP2Shell”的PHP安全事件，暴露出的问题远不止危险漏洞本身。此次发布还引发了一场关于协同披露机制的争议，同时凸显出随着AI辅助研究人员发现和开发漏洞利用方式的速度加快，开源项目维护者所承受的压力正在不断增大。

走向此次安全事件的路径，要追溯到OpenAI的”修补地球”（Patch the Planet）计划。安全公司Calif在参与该计划的过程中，使用GPT-5.6 Sol发现了一条可实现远程代码执行的攻击路径，并于8月11日向PHP项目报告了这一问题。同一天，OpenAI独立报告了相同的底层问题；Wiz公司则于8月24日报告了其发现。修复工作由PHP维护团队主导完成。事实上，维护团队早在2024年就已发现这一底层内存溢出问题的迹象，但其完整影响范围直到今年8月才完全明晰。

“这几乎是严重漏洞影响范围最广的一次。”

“这几乎是严重漏洞影响范围最广的一次，”OX Security公司的Moshe Siman Tov Bustan在一份声明中表示。”如果你有可公开访问的PHP实例且尚未打补丁，就应假定自己已暴露在风险之中。如果发现有被利用的证据，就要假定系统已被攻陷，而不仅仅是暴露风险。”

OX Security首席执行官Neatsun Ziv补充道：”这就是互联网级别漏洞的典型样貌。当一个漏洞影响到如此普及的技术时，其冲击范围不会局限于某一个产品或某一个行业，而是整个互联网本身。”

在这些警告背后，开源社区领袖们正在就一个问题展开讨论：当漏洞发现速度超过修复速度时，整个行业该如何应对。The New Stack此前曾报道过AI生成的漏洞报告给维护者带来的巨大压力；而PHP此次事件又增加了一个新的争议点——一旦细节开始泄露，禁运期是否还能真正保护用户。

披露争议与一次失误的承认

在补丁正式发布之前，PHP2Shell的相关细节就已开始泄露。PHP基金会表示，两个CVE编号于10月20日就已流传，随后一个概念验证视频也被意外公开发布。

Chainguard首席执行官兼联合创始人Dan Lorenc随后发布了已打补丁的容器镜像，比10月21日的协同发布时间提前了六个多小时。他表示，自己之所以做出打破禁运期的决定，是因为相信当时已出现攻击者正在实际利用漏洞的报告。

速度方面的担忧确实真实存在：WordPress在9月22日发布7.1.2版本修复CVE-2026-87902后，Patchstack当天就观察到有人针对WordPress网站进行探测，次日便出现了写入文件的尝试行为。

顺便说一下，这件事本身已经够糟糕了。但WordPress这一事件本身并不能证明，在Chainguard发布镜像时，攻击者是否已成功利用了这些PHP漏洞。

Lorenc为何提前行动

在给The New Stack的一封邮件中（后来也体现在他的LinkedIn帖子中），Lorenc表示，Chainguard通过自己的测试工具链，以及提示一个前沿AI模型去”寻找PHP中的严重漏洞”，独立发现了同一个问题。

Lorenc表示，Chainguard在10月16日星期五首次得知有一个PHP问题即将曝出。当晚公司便独立发现了该问题，并于10月17日星期六获得了完整的情况说明，随后协助测试了修复方案。

他表示，消息从10月19日星期一开始泄露，到周二晚间讨论进一步升温，当时有多家厂商报告了他们认为是野外攻击利用的证据。

Lorenc写道，在与其他研究人员进行视频通话后，他决定发布修复方案，并立即通知了披露工作组。他表示，他认为协同披露准则允许在有野外利用证据的情况下提前发布补丁。

Lorenc表示，三个因素促成了这一决定：Chainguard独立发现该漏洞并构建出利用方式的难易程度、当时已流传的关于漏洞及修复方案的信息量，以及已共享的关于活跃利用行为的证据。

Chainguard将打了补丁的镜像公开发布，而不是仅限内部客户使用。Lorenc承认PHP基金会并不认同他的这一决定。

他们显然并不认同。PHP基金会的说法更为直接：”Chainguard单方面打破了禁运协议，发布了包含修复方案的已构建镜像。”基金会表示，Chainguard本应提前拿到补丁，以便其客户在约定的披露时间进行更新。

在基金会看来，公开发布已构建的镜像，等于给了攻击者研究修复方案的机会，而当时其他PHP用户仍在等待补丁发布。

“我们不会总是做出完全正确的决定，也不是每个人都会认同我们的决定。”

Lorenc写道，他对自己的决定给PHP维护团队带来的压力感到抱歉。”我们不会总是做出完全正确的决定，也不是每个人都会认同我们的决定，”他表示，并补充说Chainguard的目标是保护尽可能多的用户。

什么才算得上是”漏洞利用”？

争议的核心在于：什么才能算作活跃利用的证据。Lorenc表示其他厂商已经观察到了野外利用行为。而PHP基金会则表示，在发布补丁时，其安全团队并未在当时流传的概念验证代码中发现任何一个功能完整的漏洞利用方式。

亚马逊威胁情报团队后来报告称，10月17日曾有一次针对其蜜罐系统的明显漏洞利用尝试，10月21日早间又出现了更多尝试行为。不过，该团队表示尚不清楚这些尝试在真实系统上是否会成功。

两种相互竞争的风险都是真实存在的。确实，维持禁运期可以让各分发商有时间协同准备更新；也确实，提前发布修复方案可能保护到能够获取补丁的用户。但这同样会给攻击者提供线索，而彼时其他PHP用户仍在等待补丁。

隐藏在背后的根本性问题

PHP基金会同时也承认了其应对工作中存在的另一处失误。开发人员早在2024年的一次代码审计中就注意到了导致其中一个CVE漏洞的内存溢出问题的迹象，但当时并未找到切实可行的远程代码执行路径。

基金会表示，当时的几种候选修复方案都存在棘手的兼容性和安全性权衡问题，相关工作因此屡次陷入停滞。基金会将这一延误称为”一次结构性失误”，原因在于其决策流程和资源不足。

The New Stack此前曾报道过有偿维护与安全实践之间的关联。目前，该基金会正在寻求依赖PHP的企业、主机服务商以及政府机构提供更多支持。

Ubuntu Linux的母公司Canonical对整体应对工作的评价则相对没那么严厉。该公司安全工程经理Luci Stanescu在一封电子邮件中表示：”Canonical支持并推荐依照最佳实践进行协同漏洞披露。第三方提前泄露禁运信息确实令人遗憾，但我们认为整体披露流程运作良好。”

这一评价在侧重点上与PHP基金会的批评有所不同：一次信息泄露可能会损害流程中的某个环节，但未必会使整个协同工作机制的效果全盘失效。

对于CIQ公司首席技术官Peter Nelson而言——该公司是Rocky Linux的创始赞助方——此次PHP事件正契合了Linux安全领域正在发生的一场更广泛的变化。

“过去六个月里，我们已经看到AI被用于挖掘内核层面的漏洞，”Nelson表示。”这代表着更多的研究正投向PHP等其他被广泛使用的软件程序。我们预计，随着开源项目持续利用AI及其他手段来强化代码、提供更强的防御能力以应对此类漏洞，这种趋势还会进一步增多。”

“今天，利用这类漏洞还需要前沿模型的支持。但到了明天，情况就不会是这样了。”

Nelson预计，随着先进漏洞研究能力变得越来越容易获取，这种压力还会持续存在。”今天，利用这类漏洞还需要前沿模型的支持。但到了明天，情况就不会是这样了。”

Lorenc同样将这一挑战定位为一个全行业共同面对的问题，而非仅限于PHP一个项目。”遗憾的是，这已经成为这个行业的新常态，我们需要像一个团队那样协同合作，才有机会以足够快的速度保护好我们的关键基础设施，阻止攻击者造成实质性的危害。”

补丁修复不能再等待常规维护窗口期

对企业用户来说，当下最直接的影响体现在运营层面。Red Hat副总裁兼Lightwell业务总经理Gunnar Hellekson（Lightwell是Red Hat与IBM联合开展的、旨在应对存在漏洞的开源依赖项问题的项目）在给The New Stack的邮件中表示，此次PHP漏洞事件表明，那些组织机构日常几乎不会多加留意的、看似可靠稳定的软件，实际上也存在风险。

Hellekson表示，即便AI驱动的漏洞发现工作正在不断提升漏洞发现的数量和速度，稳定运行的生产软件依然很容易被人忽视。他表示，此次PHP相关问题提醒我们，开源软件已经深深嵌入到支撑企业运营的各类系统之中。

他特别强调，企业应从可信供应商处获取经过测试的更新，尤其是在漏洞影响到像PHP这样至关重要的程序时更应如此。”鉴于这些漏洞可能造成的影响，Red Hat建议客户一旦获得来自包括Red Hat等可信来源的、经过验证和测试的补丁，就应立即部署，即便这超出了常规的补丁更新窗口期。”

“支撑着数百万个网站运行的软件，不能仅仅依靠少数几位维护者去独自应对日益复杂的安全威胁。”

除此之外，总体而言，开源软件的维护和安全工作还需要更多的资源投入。正如HackerOne首席执行官Kara Sprague在一份发给媒体的声明中所说：”PHP此次的漏洞发现同时也提醒我们，开源安全是每个人共同的责任。支撑着数百万个网站运行的软件，不能仅仅依靠少数几位维护者去独自应对日益复杂的安全威胁。”

确实，确实不能这样。

对于运行着受影响PHP系统的组织机构而言，”立即打补丁”这一紧迫问题依然存在：需要部署已修复的构建版本，并对系统进行排查，检查是否存在被尝试利用的迹象，排查范围应回溯至10月17日。

正是在这一点上，各方不同的评价意见趋于一致。获得更充分资金支持的维护团队、更具韧性的披露流程，以及更广泛可及的防御工具，或许能够解决这一长期存在的问题。而这，正是本周补丁事件背后所隐藏的那个根本性问题。