作者：OpenAI 安全团队

编译：深潮 TechFlow

深潮导读：OpenAI 在其最新的负责任漏洞披露报告中透露，其内部 AI 智能体在开源编程语言 PHP 中提前挖掘出两项影响波及全球数百万网站的严重底层漏洞。通过与 PHP 维护团队、Cloudflare 及政府安全机构协同，OpenAI 在公开披露前为防御体系争取到了数月的加固补丁窗口期，并宣布斥资 10 亿美元设立 Daybreak 计划补贴一线防御者，展示了尖端 AI 技术从被动代码审计向网络安全主动防御体系演进的重大突破。

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

对于使用 PHP 的组织，当务之急是部署修复。我们正以 Codex 技能的形式提供 PHP 版本检查工具 ，帮助运维人员识别可能存在漏洞的 PHP 版本，并结合 PHP 官方及其服务商的指导，确定需要应用哪些更新。

考虑到这些漏洞的严重程度和 PHP 的广泛使用，我们认为这是近年来影响最大的安全问题之一。这表明 AI 能够发现影响波及整个互联网的安全漏洞，但同样的能力也可能帮助攻击者快速开发攻击工具和漏洞利用程序。

据我们所知，前沿 AI 比攻击者更早发现了这些漏洞，为维护者和安全服务商打开了防御者窗口期，使其能够在漏洞披露前准备好修复和防护措施。

为帮助更多防御者运用这些能力，我们已承诺通过面向一线防御者的 Daybreak 计划，提供价值 10 亿美元的 Daybreak 使用补贴，重点支持安全资源有限、承担关键服务防护职责的组织。

尽管这些漏洞影响重大，但它们只是我们已经发现并正在着手修复的多个重大漏洞中的一部分。我们预计，未来几个月类似发现将大幅增加。基于迄今积累的经验，我们提出了一套适应 AI 时代的方法，用于应对广泛使用的软件中的严重漏洞，并邀请安全社区协助完善这一框架。这一框架将我们的模型、安全专业能力与维护者的力量汇聚起来，帮助把漏洞发现转化为防护措施，并建立能够随 AI 能力进步而扩大规模的响应机制。

协调全球响应

要让修复真正落地，可能需要将其适配到旧版本、为服务商准备缓解措施，并更新众多组织的系统。随着更多漏洞被发现，一套可重复执行的流程能帮助这些团队迅速行动。

通过 Patch the Planet，我们提供了安全专业支持和模型访问权限，助力 PHP 漏洞响应，并与维护者及研究合作伙伴一起测试修复、编制指导材料。我们还协助与基础设施服务商协调受影响系统的防护工作，并联络政府网络安全机构，帮助将指导信息传达给关键组织。这些工作支持了由维护者主导的响应，也帮助其他防御者做好准备。

对于某些漏洞发现，研究人员可以直接与软件维护者合作，调查问题并开发修复方案。另一些漏洞则需要更广泛的协同响应，因为它们影响众多产品，或者分发方和服务商需要时间准备更新及防护措施。如果前沿能力并未显著领先于已广泛普及的能力，这段时间可能十分紧迫。在这些情况下，我们提出的框架可以帮助维护者确定需要哪些参与方，并协调相关工作。响应流程可包括五个阶段：

• 验证并修复上游漏洞。维护者、研究人员和必要的技术合作伙伴共同确认漏洞、评估影响，并开发和测试修复方案。这一过程包括使用前沿模型开展对抗性测试，寻找绕过补丁的方法及相关漏洞变体。

• 为受影响组织留出行动时间。我们提出了一套框架，用于评估哪些组织需要提前获取信息以准备防护措施；具体邀请谁参与，则由维护者决定。我们协助开展联络、处理信息共享协议，并协调各团队的工作。分发方可能需要将修复适配到旧版本，托管服务商可能需要测试缓解措施，而安全服务商可能需要准备检测或预防措施，包括 Web 应用防火墙（WAF）规则。

• 与政府合作伙伴协调，协助保护关键系统。政府机构在协调更广泛的响应，以及将安全指导传达给负责关键基础设施和其他关键服务的组织方面，发挥着不可或缺的作用。在 PHP 漏洞响应中，我们与合作伙伴携手，联络了美国政府的多个部门，包括白宫超级智能工作组、国家网络总监办公室（ONCD）、网络安全与基础设施安全局（CISA），以及国际合作伙伴，以支持这项工作。

• 为各受影响产品准备更新。随着修复方案、指导材料和披露计划趋于稳定，维护者可以邀请更多分发方、托管及其他服务商、响应团队和运维人员参与，准备更新并弥补覆盖缺口。

• 补丁一旦可用，就发布指导并支持部署。公开指导有助于人们评估自身面临的风险，找到权威来源的更新或临时缓解措施，并确认修复已生效。在运维人员部署更新并反馈需要协助之处的过程中，响应工作仍将继续。

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

每个参与方都会获得开展防护工作所需的信息，范围从包含失陷指标的网络日志，到更敏感、可实际运行的概念验证漏洞利用程序。即使是有限的细节也可能暴露漏洞，因此我们会权衡共享这些信息的风险与其带来的防护收益。

遵循这一框架的团队将与维护者合作，为防御者留出准备时间；如果出现漏洞已被实际利用、信息泄露、公开补丁暴露漏洞，或修复停滞导致用户风险上升等情况，则会重新评估时间安排。

Patch the Planet 网站汇集了公开披露信息和指导材料，帮助运维人员识别受影响系统、找到合适的更新，并验证更新后的软件是否正常运行。针对 PHP，该网站提供了维护者发布的官方补丁、升级说明以及合作伙伴技术研究的链接。这些指导还涵盖临时缓解措施、何时需要服务商或专家介入，以及备份与恢复。临时防护措施能够降低风险，但我们也会明确说明其局限性，以及运维层面需要作出的权衡。

运维人员可以参考 CISA 关于优先级排序和修复的指导，根据暴露程度、漏洞利用情况和潜在影响，评估行动的紧迫性。这可能意味着紧急打补丁、立即采取缓解措施，或按计划更新；必要时还应同步开展取证初步研判，评估系统是否已被入侵。应随着情况变化重新评估优先级，并明确实现持久修复的路径。

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

全球协调离不开软件维护者。许多项目由小型团队运营，他们需要在日常开发之外兼顾安全报告的审查。这些团队需要帮助，以区分新问题与重复报告、评估影响，并在各个仍受支持的版本上测试修复。我们通过资金、强大模型的访问权限，以及直接的工程协助来支持这些工作。

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

我们的投入包括通过 Codex for OSS 为所有维护者提供订阅，以及直接赞助 Rust 基金会等项目，支持维护者及技术工作。各项目自行确定优先事项。可复用的测试和安全工作流程，能够减少处理未来漏洞发现所需的工作量。开源项目可以向 Patch the Planet 提交申请，获得实际操作层面的支持。

我们也在为 Daybreak 校准更多用于拦截的分类器，以帮助降低滥用风险。这需要作出艰难的权衡：旨在防止滥用的安全措施，也可能阻碍正当的安全工作。让更多人能够使用强大的模型，以及有效防范滥用，两者都至关重要。我们的目标是在限制有害用途的同时，保留防御者发现和修复漏洞所需的能力。随着能力不断进步，以及我们从这些工具的实际使用中积累经验，我们会持续调整，寻求更好的平衡。

构建更安全的软件基础

随着模型能力增强，我们有机会做到的不再仅仅是发现和修复单个漏洞。我们希望帮助工程师从一开始就构建更安全的软件。改进一个广泛使用的组件，就能在众多产品和服务中预防缺陷，或限制其影响。

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

• 从源头保障代码安全。编程模型可以帮助开发者选择更安全的默认设置、正确使用安全库，并在编写代码时发现高风险模式。在开发阶段预防漏洞，就意味着维护者和用户需要应对的紧急修复更少。

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

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

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

帮助我们完善这一方法

我们公开这一方法，是希望维护者、研究人员、响应团队、服务商和运维人员共同帮助提升其可行性。我们希望了解它在哪些方面能够发挥作用，哪些环节可能增加延误或负担，以及我们还有哪些遗漏。以往漏洞披露中的实例尤其有参考价值。

我们尤其关注以下方面：

• 披露窗口期。维护者、运维人员和防御者需要多少时间，才能准备并部署可靠的修复？哪些证据应促使我们提前披露，尤其是当部分用户能比其他用户更早获得保护时？

• 紧急打补丁。对于政府或其他运维方拥有或获授权管理的系统，如果已失去管理员访问权限，是否应利用漏洞为其打补丁？如果应当这样做，应在什么情况下进行？应采取哪些保障措施？我们可以设想这样一种最终形态：持续扫描整个互联网中的已知漏洞，一旦发现，就通知网站所有者或为系统打补丁。

• 提前通知。哪些参与方需要提前获知风险，才能采取有效的防护行动？其中是否包括我们可能遗漏的防御者？什么情况下，分阶段通知比一次性通知更广泛的群体更有效？又该如何权衡覆盖范围与泄露风险？

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

我们也欢迎大家推荐独立安全专家，帮助审查这一方法、质疑其假设，并找出缺口。您的意见将帮助我们完善响应机制，并确定支持工作的优先级。请在此分享您的反馈。

• 2026 年

• Daybreak