OpenAI Codex被曝高危漏洞

3月30日，BeyondTrust旗下Phantom Labs发布的一份报告，把OpenAI的Codex编码助手推上了风口浪尖。研究人员发现，这个被开发者广泛使用的AI工具存在一个命令注入漏洞，攻击者只需在GitHub分支名里动手脚，就能窃取敏感的OAuth认证令牌。

这不是理论风险。测试证实，GitHub令牌可以被直接提取出来，通过任务输出或外部网络请求外泄。

Codex作为ChatGPT的配套编码助手，允许开发者用自然语言指令直接操作代码仓库——生成代码、审查、发起拉取请求，全流程自动化。这些任务运行在托管容器环境里，用短期有效的GitHub OAuth令牌完成认证。便利是真的便利，但这也意味着：容器一旦失守，令牌就是敞开的保险箱。

漏洞藏在分支名处理逻辑里

问题的根源在于Codex处理分支名称的方式。当用户创建任务时，分支参数会被直接拼接到shell命令中执行环境设置。研究人员发现，这个环节完全没有做输入过滤——分支名里的特殊字符被原样送进命令行。

利用这个缺陷，攻击者可以构造恶意分支名，在其中嵌入任意shell命令。容器启动时会执行这些命令，而攻击者代码跑在OpenAI的基础设施上，权限和Codex任务本身一致。

Phantom Labs的测试很直接：注入一条命令，把环境变量里的GitHub OAuth令牌打印出来。令牌到手后，攻击者就能以Codex的权限访问仓库，在企业环境里尤其危险——Codex往往被授权访问大量仓库和工作流。

更麻烦的是，这个漏洞不只影响网页端。Codex的命令行工具、SDK、IDE插件全都中招。这些本地组件保存着用户的认证凭据，攻击者可以用同样的手法，通过后端API复现攻击。

规模化攻击：把恶意代码写进分支名

单个用户中招已经够糟，但研究人员演示了更狠的玩法。攻击者不需要逐个找目标，只要把恶意payload直接写进GitHub分支名，任何和这个分支交互的Codex用户都会触发漏洞。

想象一个开源项目，或者企业内部共享的代码库。攻击者提交一个看似正常的功能分支，名字里藏着注入命令。团队成员用Codex审查代码、生成补丁、或者只是浏览一下——令牌就被悄悄送走了。

Phantom Labs在报告中打了个比方：AI编码助手不只是生产力工具，它们是"活的执行环境"，握着敏感凭证和组织资源的钥匙。当用户可控的输入未经清理就塞进shell命令，结果就是命令注入、令牌窃取、组织级渗透，还能自动化规模化。

OpenAI的修复：三层防线

OpenAI已经通过协调披露流程修复了这个问题。补丁包括三个层面：输入验证加强、shell转义保护强化、容器内令牌暴露的管控收紧。此外还限制了任务执行期间的令牌作用范围和有效期。

这些措施算是把最明显的攻击面封住了。但报告结尾的警告值得细品：随着AI代理越来越深地嵌入开发者工作流，它们运行的容器安全、它们消费的输入安全，必须被当作核心基础设施来对待，而不是附加功能。

这个案例暴露了一个更广泛的张力。AI工具厂商在拼功能、拼集成深度，但安全模型的进化速度明显落后。Codex的容器化设计本意是隔离风险，结果分支名这个最基础的输入点成了突破口。

GitHub令牌尤其敏感。企业环境里，一个令牌可能关联着数十个仓库的读写权限，甚至能触发CI/CD流水线。传统安全审计会盯着代码本身，但AI代理的工作方式让攻击面转移到了"AI如何理解并执行人类指令"这个环节。

Phantom Labs的研究人员没有透露漏洞披露的具体时间线，只提到是"协调修复"。从报告发布时间倒推，OpenAI应该有数周时间准备补丁。这种节奏在AI安全领域已经算快——考虑到模型部署的复杂性，以及Codex作为ChatGPT子服务的依赖关系。

对普通开发者来说，最直接的启示是：检查你的GitHub令牌权限范围。Codex需要多少，就给多少，别图省事开全局访问。企业安全团队则需要重新评估AI工具的接入策略——不是问"这个功能有没有用"，而是问"这个功能被攻破后，最坏情况是什么"。

报告最后引用了Phantom Labs的总结：「AI编码助手不只是生产力工具。它们是活的执行环境，握着敏感凭证和组织资源的钥匙。」这句话被重复了两次，在报告正文和结论里各出现一次。研究人员显然想强调，业界对这类工具的风险认知还停留在"效率提升"的框架里，而攻击者已经在研究怎么把它们变成渗透跳板。

一个分支名能做什么？在修复之前，答案是：偷走你的GitHub身份，然后以你的名义继续行动。现在补丁已经上线，但下一个类似的输入点会在哪里——是commit消息、issue标题，还是AI代理解析的其他"无害"文本？