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/articles/openai-codex-security-issues-curated-plug-d8ba6dc7.md.
OpenAI 正通过 Codex Security 和 Patch the Planet 使用人工智能发现软件漏洞，但 Codex 自身也曾面临插件同步、沙箱和供应链缺陷。本指南区分已确认事件、厂商声明、修复信息和可执行的安全经验。
OpenAI 在 2026 年持续将人工智能更深入地应用于软件安全领域。
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 辅助的漏洞研究与人工审核结合起来，使维护者能够收到经过检查的漏洞发现，并可能同时获得补丁和测试。
其核心信息很直接：人工智能可以同时提高软件创建和漏洞发现的速度，因此防御团队需要更快地审查和修复代码。
原报道所强调的讽刺之处在于：用于发现他人漏洞的同类编码智能体基础设施，也已经成为安全研究人员关注的高价值目标。
原报道将一项新发现的 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。
零日计划组织者的官方首日结果显示，Compass Security 成功利用了 OpenAI Codex 中的 CWE-150 问题，并获得 4 万美元 和 4 个 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 的补丁路径，可能突破预期的工作区写入边界。
Heapjack 针对 Codex Desktop 使用的 JavaScript 辅助程序。研究人员称，即使 Codex 运行在只读模式下，该问题也可能最终导致在无沙箱环境中执行命令。
研究人员表示，OpenAI 在 8 天内修复了这两个问题。
其公开修复指南称，用户应更新到以下版本：
| 问题 | 研究人员报告的修复版本 |
|---|---|
| Overpatch | Codex CLI 0.149.0 或更高版本 |
| Heapjack | Codex Desktop 构建版本 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。发布上线后并帮你获取客户和流量。
用户注册赠送一次完整项目生成
适合先体验一次完整生成流程，快速看到项目初稿。
每一层也可能引入新的安全边界。
因此，“模型处于沙箱中”本身并不是完整的安全论证。
智能体平台还必须证明，更新器、插件加载器、文件编辑器、终端桥接器、网络代理、辅助守护进程和凭据路径都遵循相同的安全假设。
原报道的更广泛观点是，人工智能正在加速软件安全的两端。
在开发端，编码智能体可以比传统人工工作流更快地创建功能、测试、基础设施、集成，甚至完整项目。
这增加了新代码的产出量。
在防御端，Codex Security 和涂龙凤等系统旨在分析大型代码库，并以机器规模发现漏洞。
这提高了新旧漏洞被发现的速度。
这两种趋势会相互强化。
更多代码意味着更大的攻击面。
更强的安全自动化则会发现更多攻击面。
这并不一定会让软件生态变得更不安全。但它确实意味着，安全审查必须以更接近 AI 辅助开发的速度运行。
编码智能体在软件栈中处于一个特殊位置。
它们位于用户最终安装的应用程序上游。
它们可能访问：
普通聊天机器人的故障可能只会产生错误答案。
编码智能体的故障有时可能导致文件被修改、进程被启动、代码仓库被更改、凭据被暴露，或构建路径被入侵。
因此，编码智能体安全越来越接近终端安全和软件供应链安全，而不只是模型安全。
OpenAI 当前的沙箱指南也反映了这一现实。该指南建议隔离工作负载、限制出站网络访问、分离凭据、将应用密钥置于智能体执行环境之外，并针对重要操作使用独立的审批控制。
原报道的最后三分之一聚焦于 360 涂龙凤，以及防御者和攻击者之间的竞争。
核心观点是成立的：无论厂商是否知道，漏洞都客观存在。
如果防御者先发现漏洞，就有机会在漏洞被大规模利用之前修复系统。
如果攻击者先发现漏洞，同一个缺陷就可能演变为安全事件。
这正是自动化漏洞研究背后的经济学逻辑。
OpenAI 的 Codex Security 和 Patch the Planet 计划也建立在同一前提之上，尽管它们来自不同的组织。
其目标是将漏洞发现提前到软件生命周期的更早阶段。
360 将涂龙凤描述为一个由两个部分组成的 AI 漏洞发现系统：
360 表示，该产品已经用于测试源代码、二进制文件、固件、业务系统和 AI 工具链。
该公司还表示，截至 2026 年 8 月下旬至 9 月，涂龙凤已经发现了 超过 1 万个漏洞。
这一数字是 厂商报告的累计数字。
360 社区在 8 月 25 日发布的一则公告称，该系统已发现超过 1 万个漏洞，近 400 家组织已经接入并完成安全测试。随后 9 月的一则帖子再次重复了这一超过 1 万的数字。
原报道还称，有 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，并在 8 天内修复。
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 编码工具如今已经是上游软件基础设施。它们自身的安全控制必须以与其帮助构建的软件和供应链相同的严谨程度来对待。
从一句话开始，几分钟内拿到完整网站。
