OpenAI 联合多方修补 PHP 高危漏洞

过去两个月，我们牵头组建了一个由维护者、研究人员和安全服务商组成的联盟，共同应对 PHP 这一开源编程语言中的关键漏洞。PHP 广泛用于运行网站和 Web 应用程序。作为我们的 Patch the Planet⁠(opens in a new window) 计划的一部分，Calif 利用 GPT‑5.6 Sol 发现了一个严重缺陷；与此同时，Wiz 也独立发现并报告了这两个漏洞。PHP 的维护者主导了修复工作和版本发布，而我们的团队以及 Wiz、Cloudflare 等合作伙伴则提供了研究支持、技术协助和协调工作，以便在披露前准备好防护措施。

对于使用 PHP 的组织而言，当前的首要任务是应用这些修复补丁。我们正在分享一个 PHP 版本检查工具，并将推出配套的 Codex 技能，帮助运维人员识别可能存在漏洞的 PHP 版本，并结合 PHP 官方及其提供商的指导，确定需要应用哪些更新。

鉴于这些漏洞的严重性以及 PHP 的广泛使用，我们认为这是近年来最具影响力的安全问题之一。它凸显了 AI 如何能够发现具有互联网规模影响的安全缺陷，但同样的能力也可能被攻击者用来快速开发攻击工具和漏洞利用代码。

据我们所知，前沿 AI 在攻击者之前发现了这些漏洞，从而为维护者和安全服务商开启了一个 Defender’s Window（防御者窗口），使其能够在披露前准备好修复方案和防护措施。

为了帮助更多防御者利用这些能力，我们通过 Daybreak for Frontline Defenders 承诺提供价值 10 亿美元的补贴 Daybreak access，重点支持那些资源有限但负责保护关键服务的安全组织。

尽管这些漏洞意义重大，但它们只是我们已经发现并正在努力修复的多个重大漏洞中的一部分，且我们预计未来几个月类似发现的数量将急剧增加。基于目前的经验，我们提出了一种适用于 AI 时代的应对广泛使用软件中关键漏洞的方法，并邀请安全社区共同完善这一框架。该框架整合了我们的模型、安全专业知识以及维护者力量，旨在将发现转化为防护，并构建一种能够随着 AI 能力提升而扩展的响应机制。

协调全球响应

将修复方案投入实际使用，可能意味着需要将其适配到旧版本、准备供应商缓解措施，以及更新众多组织的系统。一套可重复的流程有助于这些团队在发现更多漏洞时迅速采取行动。

通过“Patch the Planet”计划，我们贡献了安全专业知识和模型访问权限以支持 PHP 的响应工作，并与维护者及研究合作伙伴合作测试修复方案并制定指导方针。我们还协助与基础设施提供商协调受影响系统的保护措施，并与政府网络机构接洽，以帮助指导方针触达关键组织。这支持了由维护者主导的响应工作，并帮助其他防御方做好准备。

对于某些发现，研究人员可以直接与软件维护者合作调查问题并开发修复方案。而其他发现则需要更广泛的响应，因为它们影响许多产品，或者因为分销商和服务提供商需要时间（如果前沿能力并未大幅领先于广泛可用的能力，这段时间可能会很紧张）来准备更新和保护措施。在这些情况下，所提议的框架可以帮助维护者确定需要哪些相关方参与并协调工作。响应过程可分为五个阶段：

• 验证并修复上游漏洞。 维护者、研究人员和关键技术合作伙伴确认发现结果，评估其影响，并开发和测试修复方案。此过程包括利用前沿模型进行对抗性测试，以寻找绕过补丁的方法以及与该漏洞相关的变体。

• 为受影响组织留出行动时间。 我们提出了一个框架，用于考虑哪些组织需要提前获取信息以准备保护措施，同时由维护者决定邀请谁参与。我们在外联、信息共享协议以及团队间协调方面提供支持。例如，分销商可能需要将修复方案适配到旧版本，托管服务提供商可能需要测试缓解措施，而安全服务提供商可能需要准备检测或预防措施，包括 Web 应用防火墙（WAF）规则。

• 与政府合作伙伴协调，协助保护关键系统。 政府机构在协调更广泛的响应行动、帮助安全指南触达负责关键基础设施及其他基本服务的组织方面发挥着至关重要的作用。以 PHP 为例，我们与合作伙伴协作，与美国政府的多个部门（包括白宫超级智能力量团队、国家网络总监办公室 (ONCD)、网络安全和基础设施安全局 (CISA)）以及国际合作伙伴共同支持这一工作。

• 为受影响的产品准备更新。 随着修复方案、指导方针和披露计划趋于稳定，维护者可以引入更多的发行版提供商、托管和服务提供商、应急响应团队以及运维人员，以准备更新并填补覆盖范围的空白。

• 补丁发布后，公开指导并支持部署。 公开的指导信息有助于人们评估自身暴露风险，查找权威的更新或临时缓解措施，并确认修复是否已生效。随着运维人员部署更新并反馈所需协助，响应工作将持续进行。

所提出的框架考虑了组织的防护角色，包括保护其自身系统和客户、采取行动所需的时间，以及处理敏感信息的能力。同样的标准将适用于类似的组织，由维护者在披露前决定邀请哪些方参与。

每位参与者都会获得执行其防护工作所需的信息，从包含失陷指标的网络日志到更为敏感的初步概念验证利用代码。即使是有限的细节也可能暴露漏洞，因此我们在共享信息的风险与其带来的保护作用之间进行权衡。

遵循此框架的团队将与维护者合作，为防御者争取准备时间；如果野外存在主动利用、发生泄露、公开补丁揭示漏洞，或因修复停滞导致用户风险增加，则需重新评估时间表。

Patch the Planet 网站⁠（在新窗口中打开）汇集了公开披露信息和指导方案，旨在帮助运营方识别受影响的系统、找到合适的更新版本，并验证更新后的软件是否正常运行。针对 PHP，该网站指向了维护者提供的官方补丁和升级说明，以及我们合作伙伴的技术研究成果。相关指南还涵盖了临时缓解措施、何时需要引入服务提供商或专家支持，以及备份与恢复策略。临时防护措施可以降低风险，但我们会明确说明其局限性及相应的运维权衡。

运营方可参考 CISA 关于优先级排序和修复的指导⁠（在新窗口中打开），根据暴露面、利用情况和潜在影响来评估行动的紧迫程度。这可能意味着紧急打补丁、立即采取缓解措施或计划性更新，并在必要时进行取证分析以评估系统是否已被入侵。随着情况变化，应重新评估优先级，并制定通往长期修复的清晰路径。

为维护者提供响应所需的能力和资源

全球协调依赖于那些维护软件的人员。许多项目由小型团队运营，他们在处理日常开发工作的同时，还要审查安全报告。这些团队需要协助区分新出现的问题与重复项、评估影响范围，并在所有受支持的发布版本中测试修复方案。我们通过资金支持、提供高性能模型访问权限以及工程技术支持来助力这项工作。

强大的 AI 能力正在整个行业中快速发展，我们预计 AI 将在帮助防御者发现漏洞、监控系统以及应对威胁方面发挥越来越重要的作用。我们正在投资模型、工具和合作伙伴关系，以帮助防御者将这些能力付诸实践。

我们的投资包括通过 Codex for OSS 为所有维护者提供订阅服务，以及直接赞助诸如 Rust Foundation⁠(opens in a new window) 等项目，以支持维护者和技术工作。每个项目都会设定自己的优先级。可复用的测试和安全工作流可以减少处理未来发现所需的工作量。开源项目可以 申请加入 Patch the Planet⁠(opens in a new window) 以获得实操支持。

我们也在为 Daybreak 校准额外的拦截分类器，以帮助降低潜在滥用风险。这涉及艰难的权衡：旨在防止滥用的安全措施也可能阻碍合法的安全工作。对强大模型的广泛访问和有效的防滥用保护都至关重要。我们的目标是在限制有害使用的同时，保留防御者发现和修复漏洞所需的能力。随着能力的提升以及我们对这些工具使用方式的学习，我们将继续完善这一平衡。

构建更安全的软件基础

随着模型变得更加强大，机遇已超越发现和修复单个漏洞的范畴。我们希望帮助工程师从一开始就构建更安全的软件。对广泛使用的组件进行改进，可以在许多产品和服务中预防错误或限制其影响。

AI 可以帮助工程师理解现有代码、准备更改并开发测试，而维护者和安全专家则负责验证这些更改是否保留了用户依赖的行为。我们在以下几个领域看到了机会：

• 从一开始就编写安全代码。 编码模型可以帮助开发者选择更安全的默认设置，正确使用安全库，并在编写过程中捕捉高风险模式。在开发阶段预防漏洞意味着维护者和用户需要进行的紧急修复更少。

• 内存安全的软件。 将关键组件迁移到内存安全的语言可以消除常见的内存错误类别。AI 可以协助迁移工作，并通过测试和专家审查来检查行为兼容性和正确性。

• 形式化验证。 数学证明可以表明，在既定假设下，关键组件满足指定的安全属性。将这些方法应用于广泛使用的组件，有助于排除依赖这些组件的服务和关键基础设施中存在的各类漏洞。

• 更强的隔离机制。 系统需要防范那些尚未被发现或修复的漏洞。在严格限制的沙箱中运行处理不可信文件、图像或媒体的软件，可以在软件被攻破时限制损害范围。AI 可以帮助工程师测试并加强广泛使用的沙箱技术，从而提升众多应用的安全防护水平。

帮助我们改进这一方案

我们分享这一方案，旨在让维护者、研究人员、应急响应团队、服务提供商和运营方共同协助使其切实可行。我们希望了解该方案在哪些方面能提供帮助，在哪些方面可能增加延迟或负担，以及我们遗漏了哪些内容。过往披露案例中的具体示例将尤为宝贵。

我们特别关注以下方面：

• 披露窗口期。 维护者、运营方和防御者需要多少时间来准备并部署可靠的修复措施？哪些证据应触发更早的披露，特别是当部分用户能比其他用户更早得到保护时？

• 紧急补丁。 政府或其他运营方在失去管理权限后，是否以及在何种情况下应利用漏洞来修补其拥有或获授权管理的系统？应适用哪些保障措施？我们可以设想一种最终状态：对互联网进行全天候扫描以检测已知漏洞，并在发现漏洞时通知网站所有者或直接修补系统。

• 提前预警。 谁需要提前警告以便采取有效的保护措施，包括我们可能忽略的防御者？分阶段通知何时比一次性通知更广泛的群体更有效？我们应如何权衡覆盖范围与泄露风险？

• 默认安全的软件包。 在上游修复尚未完成期间，我们如何帮助识别并修复下游软件包中的漏洞，或将修复回移植到不再接收安全更新的旧版本？需要进行哪些测试和维护工作，才能使这些软件包在无法及时升级的情况下成为可靠的选择？

我们也欢迎推荐能够审查该方案、挑战其假设并识别漏洞的独立安全专家。您的反馈将帮助我们完善应对措施，并确定支持工作的优先级。在此分享您的反馈⁠（在新窗口中打开）。