For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/zh-HK/articles/openai-codex-security-issues-curated-plug-d8ba6dc7.md.
OpenAI 正通过 Codex Security 和 Patch the Planet 利用 AI 发现软件漏洞，但 Codex 自身也曾面临插件同步、沙箱及软件供应链缺陷。本指南区分已验证事件、供应商声明、修复信息与实际安全经验。
OpenAI 在 2026 年投入大量资源，将 AI 更深入地应用于软件安全领域。
3 月，OpenAI 以研究预览版形式推出了 Codex Security。这是一款应用安全智能体，旨在发现、验证并协助修复漏洞。6 月，OpenAI 又推出了 Patch the Planet，这是与 Trail of Bits 合作开展的 Daybreak 计划，重点帮助开源维护者发现并修复安全问题。7 月底，OpenAI 还发布了开源版 Codex Security CLI 和 TypeScript SDK。
这使得围绕 Codex 的安全故事格外重要。
Codex 不只是一个代码生成模型。它是一款连接本地与云端的编码智能体，能够读取代码仓库、编辑文件、调用工具、运行命令、加载插件、连接 MCP 服务，并运行在通常包含源代码和凭据的开发环境中。
9 月，一篇由 BAAI/新智元发布的报道强调了一项归因于中国 AI 安全测试系统 360 图灵凤 的新 Codex 安全声明。报道称，该问题涉及 Codex 的精选 Git 插件同步路径，并可能绕过用户在执行敏感操作前通常期待的审批边界。
这项由 360 提出的具体新发现，目前尚未得到 OpenAI 公开安全公告或详细公开技术报告的支持，因而无法独立证明它是一个独立的新型零日漏洞。不过，文章所描述的更广泛风险是真实存在的：此前公开的 Codex 问题报告已经显示，精选插件的启动同步可能在模型沙箱之外运行，并且在特定 Git 环境条件下操作用户的代码仓库，而不是插件缓存。
这种区别很重要。本文保留原始报道的结构，同时区分 已确认的公开事件、研究人员报告的发现 和 归因于供应商的声明。
OpenAI 于 2026 年 3 月 6 日推出了 Codex Security。
该产品旨在建立对代码库的上下文理解，识别安全弱点，验证某项发现是否具有实际意义，并提出修复方案。与简单的模式扫描器不同，OpenAI 将其定位为一种智能体式安全系统，能够跨项目进行推理并减少误报。
随后，OpenAI 通过 Patch the Planet 扩展了这项工作。
该计划将 AI 辅助的漏洞研究与人工审查结合起来，使维护者收到经过检查的漏洞发现，并可能同时获得补丁和测试。
其核心信息很直接：AI 能够同时提升软件开发和漏洞发现的速度，因此防御团队需要更快地审查和修复代码。
原始报道强调的讽刺之处在于：用于发现他人漏洞的同类编码智能体基础设施，也已经成为安全研究人员眼中的高价值目标。
原始报道将一项新发现的 Codex 漏洞归因于 360 的图灵凤系统，并称该问题与 Codex 的 精选 Git 插件同步机制 有关。
在正常使用中，Codex 依赖多项安全控制：
当启动代码或基础设施代码在与模型驱动命令不同的沙箱之外运行时，风险就可能出现。
这一差异已经在公开的 Codex 问题报告中有所体现。
7 月的一项 GitHub 问题报告记录了这样一种情况：精选插件的启动同步过程执行 Git 命令时，没有完全隔离仓库本地的 GIT_* 环境变量。当 Codex 在特定 Git hook 或 worktree 环境中启动时，同步过程可能操作用户的代码仓库，而不是预期的插件缓存。
报告者特别指出，--sandbox read-only 并不能限制这一行为，因为同步过程属于 Codex 的启动机制，而不是模型在沙箱内执行的命令。
OpenAI 于 2026 年 6 月 24 日合并了标题为 “隔离精选插件同步的 Git 环境” 的修复。围绕受影响的 0.142.x 版本和早期 0.143 版本的公开问题显示，该修复最初出现在 main 分支，之后才进入稳定版本。
这段公开历史支持了文章的更大观点：智能体的安全边界必须覆盖其 自身基础设施，而不仅是模型直接请求执行的 shell 命令。
不过，归因于图灵凤的 9 月声明是否代表一条独立于此前公开的启动同步隔离问题之外的利用路径，目前仍不清楚。在 OpenAI 或 360 发布公开公告、CVE 或技术报告之前，本版本不会将这一“新零日”声明作为已经独立确立的事实。
一种常见的 Codex 安全模型如下：
OpenAI 当前的智能体安全指南也遵循同一项更广泛的原则：高风险副作用应受到独立约束，并在必要时暂停，等待明确的人工审查。
问题在于，只有当某项操作确实经过执行审批的代码路径时，权限提示才能保护该操作。
如果后台更新器、插件同步器、辅助进程或其他受信任子系统在这一路径之外执行工作，那么可见的审批界面可能根本不是相关的安全边界。
这是 2026 年 Codex 漏洞报告中最重要的经验之一。
AI 编码工具的威胁模型不再只是：
“模型会不会请求执行危险命令？”
还包括：
“智能体平台的哪些部分能够在模型正常审批流程之前或之外修改文件、启动进程、获取代码、加载插件、读取凭据或与 Git 交互？”
原始报道通过一个软件供应链场景说明了潜在影响。
这一攻击链并不要求恶意软件通过明显恶意的下载进入系统。
更现实的过程可能是：
这就是开发者工作站成为高价值目标的原因。
开发者工作站可能包含：
第一台被入侵的机器可能并不是攻击者的真正目标。
攻击者真正想要的，可能是与开发者身份及其发布流程相关联的信任。
这正是供应链风险的核心特征：攻击者试图将一条受信任的软件路径变成传播机制。
精选插件问题只是围绕 AI 编码智能体展开的一系列安全研究的一部分。
原始报道将多起 2026 年事件放在一起，其中大多数都可以独立验证。
Pwn2Own Berlin 2026 增设了专门的 Coding Agent 类别，目标包括 OpenAI Codex、Anthropic Claude Code 和 Cursor。
零日计划（Zero Day Initiative）的官方首日结果显示，Compass Security 成功利用 OpenAI Codex 中的 CWE-150 问题，并获得 40,000 美元奖金及四个 Master of Pwn 积分。
Doyensec 也展示了针对 Codex 的利用，但由于供应商已经知悉相关底层漏洞，该结果被归类为 碰撞。
整个赛事最终发现了 47 个独特的零日漏洞，所有类别的奖金总额达到 1,298,250 美元。
Pwn2Own 是一个特别有用的参考点，因为其编码智能体规则排除了简单越狱和不安全模式。成功参赛必须通过常见的编码智能体工作流突破具有实际意义的安全边界。
8 月 12 日，360 公开表示，其图灵凤 AI 安全系统在 OpenAI Codex 中发现了 六个高价值安全漏洞。
根据 360 的公告，这些发现包括可能导致远程任意代码执行的高风险问题，以及用户打开不受信任的项目目录时绕过 Codex 信任提示的情况。
多家中国媒体以及新华社的一篇转载报道都转述了这一披露。
不过，在本文审阅的来源中，所有六项发现的详细技术报告和类似 CVE 的标识符并未公开。
因此，准确的表述应当是：
360 报告称，图灵凤发现了六个高价值 Codex 漏洞，其中包括具有远程代码执行影响的情况。
这与根据公开技术材料独立验证全部六条利用链不同。
Accomplish 的安全研究员 Oren Yomtov 于 8 月 12 日向 OpenAI 报告了两个 Codex 沙箱逃逸问题。
研究人员将其命名为 Overpatch 和 Heapjack。
Overpatch 影响开源 Codex CLI 的补丁路径，可能突破预期的 workspace-write 边界。
Heapjack 针对 Codex Desktop 使用的一个 JavaScript 辅助程序。研究人员称，即使 Codex 运行在只读模式下，它也可能最终执行未受沙箱限制的命令。
研究人员表示，OpenAI 在八天内修复了这两个问题。
其公开修复指南称，用户应更新至以下版本：
| 问题 | 研究人员报告的修复版本 |
|---|---|
| Overpatch | Codex CLI 0.149.0 或更高版本 |
| Heapjack | Codex Desktop build 26.818.21641 或更高版本 |
这些版本号来自研究人员的披露，而不是独立的 OpenAI 安全公告。
AIR Security 于 9 月 17 日披露了 Plugin4Shell。
该漏洞影响以下产品的插件安装和更新逻辑：
AIR 将其描述为一条无需点击即可实现远程代码执行的路径，其根源在于：插件安装完成后，系统没有验证实际检出的代码是否与软件市场原本指定锁定的提交一致。
由于 Codex 和 Claude Code 能够自动更新已安装的插件，之前受信任的插件可能在不要求用户再次点击的情况下，变成供应链攻击路径。
AIR 表示，OpenAI 已在 0.146.0 版本中修复 Codex。
Plugin4Shell 的重要性在于，它不是模型行为失败，而是智能体周边分发层中的经典软件供应链设计缺陷。
2026 年 Codex 的安全发现并不都源于同一个根因。
有些涉及沙箱边界。
有些涉及辅助进程。
有些涉及 Git 环境处理。
有些涉及插件分发。
但它们都扩大了 可信计算基。
现代编码智能体不再只是：
用户提示 -> 模型 -> 答案
它更接近：
用户
-> 模型
-> 智能体框架
-> 工具路由器
-> shell
-> 文件系统
-> Git
-> 插件管理器
-> MCP 服务
-> 凭据
-> 网络
-> CI/CD
每一层都会带来有用能力。
輸入一句想法，We0 AI 即可生成展示站、頁面與 CMS。發佈上線後並幫你獲取客戶和流量。
用戶註冊贈送一次完整項目生成
適合先體驗一次完整生成流程，快速看到專案初稿。
每一层也都可能引入新的安全边界。
因此，“模型处于沙箱中”本身并不是完整的安全论据。
智能体平台还必须证明，更新器、插件加载器、文件编辑器、终端桥接器、网络代理、辅助守护进程和凭据路径都遵守相同的安全假设。
原始报道的更广泛观点是，AI 正在同时加速软件安全的攻防两端。
在开发端，编码智能体能够比传统人工流程更快地创建功能、测试、基础设施、集成和完整项目。
这会增加新代码的产出量。
在防御端，Codex Security 和图灵凤等系统旨在分析大规模代码库，并以机器规模发现漏洞。
这会提升旧漏洞和新漏洞被发现的速度。
这两种趋势会相互强化。
更多代码意味着更大的攻击面。
更好的安全自动化则能够发现更多攻击面。
这并不一定意味着软件生态会变得更不安全。但它确实意味着，安全审查必须以更接近 AI 辅助开发的速度运行。
编码智能体在软件栈中处于特殊位置。
它们位于用户最终安装的应用程序上游。
它们可能访问：
普通聊天机器人的故障可能产生错误答案。
编码智能体的故障则可能产生被修改的文件、已启动的进程、被更改的代码仓库、暴露的凭据或遭入侵的构建路径。
这就是为什么编码智能体安全越来越接近终端安全和软件供应链安全，而不只是模型安全。
OpenAI 当前的沙箱指南也反映了这一现实。该指南建议隔离工作负载、限制出站网络访问、分离凭据、将应用密钥放在智能体执行环境之外，并针对具有重要后果的操作使用独立的审批控制。
原始报道的最后部分聚焦于 360 图灵凤，以及防御者与攻击者之间的竞速。
其核心观点是成立的：无论供应商是否知晓，漏洞都客观存在。
如果防御者先发现漏洞，就有机会在漏洞被广泛利用前修复系统。
如果攻击者先发现，同一个漏洞就可能演变成安全事件。
这就是自动化漏洞研究背后的经济学逻辑。
OpenAI 的 Codex Security 和 Patch the Planet 计划建立在相同前提之上，尽管它们来自不同组织。
目标是让漏洞发现更早发生在软件生命周期中。
360 将图灵凤描述为一个 AI 漏洞发现系统，由两个部分构成：
360 表示，该产品已用于测试源代码、二进制文件、固件、业务系统和 AI 工具链。
公司还称，截至 2026 年 8 月下旬至 9 月，图灵凤已经发现 超过 10,000 个漏洞。
这一数字是 供应商报告的累计数字。
360 社区 8 月 25 日的一则公告称，该系统已发现超过 10,000 个漏洞，并有近 400 家组织接入并完成安全测试。之后 9 月的一则帖子再次提到超过 10,000 个漏洞这一数字。
原始报道还声称，有 260 项发现已经获得中国漏洞管理机构验证，且接入组织接近 500 家。在本文最新审阅的 360 来源中，没有找到与这些确切数字相匹配的信息，因此本版本不会将其作为独立确认的数据重复发布。
原始报道将图灵凤的方法描述为一种递归改进形式。
这一概念与基础模型重写自身权重关系较小，更接近于从已完成的安全任务中构建可重复使用的操作记忆。
其工作流可以概括为：
这类似于安全团队构建操作手册、漏洞利用知识库、检测规则和事件响应流程的方式。
区别在于，智能体系统可能以更高速度，并行处理大量任务，从而复用这些经验。
供应商的说法是，这种机制能够将单个安全发现转化为整个智能体集群共享的能力。
文章结尾描绘的软件供应链图景值得保留。
当用户点击“更新”时，软件可能已经经过以下环节：
每个阶段都会继承前一阶段的信任。
AI 编码智能体如今位于这条链路的前端附近。
这意味着，它们自身的安全控制已经成为其帮助创建和发布的每个应用程序安全模型的一部分。
实际经验并不是开发者应停止使用编码智能体。
而是应将编码智能体视为强大的开发基础设施。
它们需要像其他特权工具一样，具备版本管理、隔离、最小权限、密钥分离、插件治理、安全监控和快速修复能力。
根据 OpenAI 当前的指南以及公开披露的 2026 年漏洞，开发者可以通过几项具体做法降低暴露风险。
已知安全修复已经快速发布。
对于上述研究人员披露的 Plugin4Shell、Overpatch 和 Heapjack 问题，受影响用户应升级到报告中提到的修复版本之后的版本。
不要认为“我只是向智能体提了一个问题”就意味着没有代码路径能够执行。
审查不熟悉的代码仓库时，应使用隔离环境。
避免直接向智能体执行环境暴露高价值的云凭据、软件包注册表凭据、签名凭据和生产环境凭据。
只允许任务所需的出站目标。
拥有任意出站能力和广泛凭据的编码智能体，其潜在影响范围会大得多。
即使是受信任的智能体，也可能通过不受信任的扩展或更新渠道遭到入侵。
应有意识地锁定版本、审计并更新插件。
对于影响较大的操作，审批应由独立的受信任组件执行，而不应只依赖运行在与智能体相同执行环境中的逻辑。
记录并审查：
模型的最终回答只是智能体行为的一部分。
Codex 使用过一种通过 Git 同步精选插件的启动机制。公开的 GitHub 问题显示，早期版本可能继承仓库本地的 Git 环境状态，并在模型沙箱之外，将同步操作执行到用户的代码仓库，而不是预期的插件缓存。
BAAI/新智元报道将一条新的精选 Git 同步攻击路径归因于 360 图灵凤。不过，目前没有发现公开的 OpenAI 公告或详细的 360 技术披露，能够独立证明这项 9 月具体声明是一个独立的新零日漏洞。因此，它应被视为一项归因报道，而不是完全验证的公开发现。
它们是 Accomplish 研究员 Oren Yomtov 披露的两个 Codex 沙箱逃逸问题。研究人员称，这两个问题均于 8 月 12 日报告给 OpenAI，并在八天内得到修复。
Plugin4Shell 是 AIR Security 于 2026 年 9 月 17 日披露的插件供应链漏洞。AIR 表示，该漏洞影响 Claude Code、Codex、GitHub Copilot 和 Gemini CLI，原因是系统无法保证已安装插件与软件市场原本指定锁定的提交一致。
是。零日计划报告称，Compass Security 在首日成功利用 Codex，Ikotas Labs 在第三日也成功利用 Codex。Doyensec 同样展示了一个利用，但由于供应商已经知悉相关底层漏洞，该结果被归类为碰撞。
OpenAI 于 2026 年 7 月将 Codex Security CLI 和 TypeScript SDK 作为开源软件发布。不过，访问部分网络安全能力和受保护发现仍可能需要适当的 OpenAI 访问权限或 Trusted Access for Cyber。
不能将任何单一模式视为绝对保证。2026 年的多项发现之所以重要，正是因为存在漏洞的组件在预期模型沙箱之外运行，或突破了原本设定的安全边界。
使用最新版本，隔离不受信任的代码，限制网络访问，将长期有效凭据放在执行环境之外，审计插件，针对具有重要后果的操作使用独立的人工审批，并记录智能体实际调用的工具和系统活动。
OpenAI 正通过 Codex Security 和 Patch the Planet 加速防御性漏洞研究，但 Codex 自身也已经成为日益重要的安全目标，因为它靠近源代码、工具、凭据、插件和软件发布工作流。
2026 年已公开验证的事件包括 Pwn2Own 中针对 Codex 的利用、精选插件启动同步隔离问题、Overpatch 和 Heapjack 沙箱逃逸，以及 Plugin4Shell。在详细公开公告说明其与早期插件同步问题的差异之前，归因于 360 图灵凤的 9 月“新零日”应当以更加谨慎的方式看待。
所有这些案例都指向同一个更大的经验：AI 编码智能体的安全边界远不止模型本身。更新器、插件管理器、Git 集成、工具运行时、辅助进程、网络访问、凭据处理和审批系统，都属于可信计算基的一部分。
AI 编码工具如今已经成为上游软件基础设施。它们自身的安全控制必须以与其帮助构建的软件和供应链相同的严格程度来管理。
從一句話開始，幾分鐘內拿到完整網站。
