AI编程助手正在接管开发者的键盘，但没人告诉过你，它也可能成为黑客的特洛伊木马。
Phantom Labs安全团队上周披露的一组漏洞，把OpenAI Codex变成了攻击者潜入企业代码仓库的跳板。他们演示了如何通过一个精心构造的分支名，让AI助手亲手把自己的GitHub访问令牌交出来。
漏洞核心：当分支名变成攻击载荷
Codex的工作流程听起来很干净——用户提交需求，系统在云端启动容器，AI在里面写代码、分析仓库、提交修改。但BeyondTrust的研究员发现，这个流程在容器启动阶段有个致命疏忽。
问题出在GitHub分支名的处理上。当Codex准备环境时，会把用户指定的分支名直接写进启动脚本，没有任何过滤。攻击者只需要把一个shell命令藏进分支名，就能在容器初始化时执行任意代码。
演示用的攻击载荷长这样：一个看似正常的分支名里嵌入了重定向指令，把系统环境变量中的GitHub OAuth令牌输出到临时文件。然后攻击者再"礼貌地"请Codex读取这个文件，令牌就以明文形式出现在聊天界面里。
Phantom Labs的研究员把这叫作"AI供应链攻击的新变种"。传统的命令注入需要找到输入口，而Codex的设计让攻击者有了无数个入口——每个被AI处理的分支都可能是一个。
本地攻击：你电脑里的认证文件也不安全
云端漏洞只是开始。研究团队接着发现了桌面版Codex的软肋：认证凭据被明文存储在本地文件里。
Windows、macOS、Linux三平台无一例外。攻击者一旦拿到开发者机器的访问权限，就能直接复制这些会话令牌。用它们向Codex后端API认证，可以拉取该用户的完整任务历史。
任务日志里藏着什么？每次Codex操作GitHub仓库时留下的访问令牌。这些令牌通常带有广泛的仓库权限，因为用户授权时图方便，很少细粒度限制AI助手的动作范围。
横向移动的路径就此打通。从一台失陷的开发机，到整个组织的代码资产，中间只隔了几个API调用。
自动化攻击：恶意分支能自己传播
最棘手的攻击场景不需要受害者主动交互。攻击者直接在共享仓库里创建一个恶意分支，命名上做点手脚——用Unicode表意空格替代普通空格，视觉上和main分支几乎无法区分。
GitHub的分支名限制被用内部字段分隔符绕过。当其他开发者或CI流程触发Codex处理这个分支时，注入的代码静默执行，把令牌外传到攻击者服务器。
Pull Request场景同样中招。开发者@Codex做代码审查时，系统启动审查容器，恶意分支名里的载荷随之运行。整个过程对发起审查的人完全透明。
Phantom Labs测算，这种"毒分支"可以在大型开源项目或企业内部仓库中被动传播，感染所有使用该仓库的Codex用户。AI助手的便利性在这里变成了攻击面的放大器——它让代码仓库的每个参与者都成了潜在的泄露节点。
OpenAI的修复与未解的问题
漏洞披露后，OpenAI在72小时内推送了补丁。分支名输入现在经过严格过滤，本地认证文件的存储方式也被重构。但安全社区的讨论没有停止。
核心争议在于AI代理的权限模型。Codex需要GitHub令牌才能工作，这意味着它必须持有高权限凭证。传统工具链里，这些凭证由开发者手动管理、按需使用；AI助手把它们变成了长期驻留的系统组件。
BeyondTrust在报告中提到一个细节：部分企业客户在漏洞披露前已经注意到异常令牌活动，但归因困难——Codex的自动化操作和正常用户行为在日志里难以区分。当AI成为开发流程的默认配置，安全监控的基础设施还没有跟上。
GitHub去年发布的AI安全指南曾警告"过度授权"风险，建议为AI工具创建专用机器账户并限制仓库范围。但调研显示，实际配置中很少人愿意牺牲便利性来做权限隔离。
Phantom Labs的研究员在技术博客末尾留了句话：「我们测试了主流AI编程工具，Codex不是唯一有这类问题的。」其他产品的容器隔离、输入验证、凭证管理是否经得起同样 scrutiny，目前没有公开答案。
企业安全团队现在面临一个选择题：是收紧AI工具的使用范围，还是押注厂商能快速修补这类架构性弱点？
热门跟贴