一个精心构造的GitHub分支名，能让AI编程助手变成你代码仓库的"内鬼"。BeyondTrust安全实验室最新披露：OpenAI Codex存在命令注入漏洞，攻击者无需接触你的代码，只需让你"看一眼"恶意分支，就能窃取完整的GitHub访问令牌。
漏洞原理：当分支名变成攻击代码
Codex的工作机制是启动托管容器，克隆用户仓库，并用短期OAuth令牌完成身份验证。问题出在环境初始化阶段——分支名称未经清理（sanitization）就直接拼接到shell命令中。
攻击者构造的分支名本身就是可执行代码。比如一个包含反引号或分号的特殊字符串，会被shell解释为命令分隔符。容器启动时，这些"命令"以Codex的权限执行，而此刻GitHub令牌正躺在环境变量里。
BeyondTrust的研究人员演示了完整攻击链：恶意分支→容器注入→令牌提取→权限持久化。整个过程不需要目标开发者编写或运行任何代码，只要Codex处理过这个分支，攻击就完成了。
更麻烦的是传播方式。把payload埋进公共仓库的分支名，每个通过Codex查看该仓库的开发者都会触发漏洞。这不是点对点攻击，而是一对多的"投毒"模式。
权限范围：不只是"读代码"那么简单
很多人以为GitHub OAuth令牌只是用来拉取代码的。在企业级Codex部署中，这些令牌往往附带广泛权限：
仓库写入权限、组织成员管理、部署密钥访问、甚至其他集成服务的凭据。BeyondTrust指出，企业环境中Codex通常被配置为"能干更多事"，而这恰恰放大了漏洞的破坏力。
一个分支名，换整个组织的代码资产。这不是理论风险——漏洞披露前，这种攻击模式已经可行。OpenAI现已修复，但修复之前有多少仓库被"扫过"，无从得知。
漏洞披露当天，Anthropic发布了Claude Code的Computer Use功能，允许AI控制鼠标和键盘。两件事撞在一起，指向同一个被忽视的真相：AI编程助手正在从"建议工具"变成"执行代理"，而安全模型还没跟上。
"氛围编程"群体的盲区
这个漏洞对专业安全人员来说不算复杂——命令注入是经典攻击类型，输入验证是基本功。但Codex的目标用户里，有相当比例是BeyondTrust所说的"vibe coders"（氛围编程者）：依赖AI生成代码、不深入理解底层机制、信任工具链的开发者。
他们不会检查Codex怎么解析分支名，不会怀疑一个静态的仓库引用能执行代码。攻击面不在他们的代码里，在他们用的工具里。
这也不是Codex独有的问题。Cursor、Windsurf、GitHub Copilot Workspace——所有能克隆仓库、执行命令、访问凭证的AI编码工具，都在把开发者的机器变成受攻击面。每新增一个功能（比如Claude Code的屏幕控制），就新增一类可能的利用方式。
OpenAI修了这个漏洞。下一个呢？下一个工具的下一个漏洞呢？
安全研究者已经在做针对性工具。BeyondTrust团队正在开发VibeCheck，一个面向"氛围编程"应用的安全扫描器。他们的判断很直接：AI编码工具的安全审查，不能指望用户自己完成。
当你的AI助手能替你写代码、跑测试、甚至操作你的电脑时，它拥有的信任级别相当于你自己。问题是，它值得这份信任吗？
热门跟贴