ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

AI编码代理暗藏致命漏洞:Claude、Gemini、Codex集体中招,开发者正坐在火药桶上

AI编码代理暗藏致命漏洞:Claude、Gemini、Codex集体中招,开发者正坐在火药桶上 当越来越多的团队把代码审查、自动修复甚至发布流程交给AI代理打理时很少有人意识到这些智能助手本身正在成为攻击者眼中最诱人的突破口。Novee安全实验室的研究员Elad Meged最近做了一项看似简单的测试——用默认配置去碰一碰Anthropic、Google和OpenAI三家主流AI编码代理的公共仓库结果令人脊背发凉。他不需要任何特权账户仅凭一个匿名的GitHub Issue提交就能让代理乖乖执行远程代码顺手把API密钥打包带走。这不是什么理论推演而是此时此刻数百万开发者正在运行的真实代码里埋着的雷。问题的根子不在大模型本身而在那些被称为外挂的中间层——负责权限管控、命令执行和沙箱隔离的外部代码。当安全机制在交接处出现缝隙整个防线就会像多米诺骨牌一样倒塌。一个匿名Issue如何撕开AI代理的防线Meged的测试方法朴素得近乎讽刺在目标仓库里开一个Issue往里面塞一段精心构造的提示注入载荷。由于这些AI代理通常被配置在CI/CD管道里自主运转没有人逐行审查它们处理的每一个Issue或Pull Request恶意指令就这样悄无声息地混进了执行队列。更棘手的是这类攻击不需要攻破任何身份验证体系。攻击者甚至不需要是项目的贡献者一个路过的陌生人就能触发整条攻击链。代理在解析Issue内容时会把攻击者的指令当作正常任务的一部分去执行——读取敏感文件、调用外部API、甚至直接向代码库推送恶意提交。整个过程中安全沙箱要么形同虚设要么在关键环节掉了链子。Anthropic Claude Code绕过二十三重安全检查的魔术在Anthropic自家的claude-code仓库里Meged团队找到了命令验证逻辑与Shell实际解析方式之间的微妙错位。具体来说Claude在验证git命令时会对带引号的字符串做一套检查但Shell解释器对同样字符串的理解却略有不同。攻击者利用这个缝隙构造了一个看似无害的git push --receive-pack参数实际上却绕过了整整23道安全检查直接在运行器上执行了任意代码。Anthropic很快修补了这个漏洞但故事远没结束。Meged很快找到了第二条路——用只读命令tac去读取任意文件。这个命令本身没有写入权限却能顺着GitHub Actions的公开日志把反向API密钥一点点漏出去。到了第三轮攻击手法进一步升级利用HuggingFace的公开下载计数器作为隐蔽的侧信道每次只泄露一个字符慢条斯理地把完整的API密钥拼接出来。这一漏洞最终被赋予CVE编号CVE-2026-54316意味着它已经被正式纳入全球漏洞数据库的追踪范围。Google Gemini CLI十万星标仓库里的信任危机Google的Gemini CLI托管在一个拥有超过10.6万Star、月安装量约200万的仓库里影响力不容小觑。Meged在这里发现了两个相互叠加的缺陷单独看哪一个都不算致命但凑在一起就成了灾难。第一个问题是受限Shell工具的允许列表从未在运行时真正生效。Gemini CLI表面上限制了可执行的命令范围但检查逻辑存在漏洞攻击者可以轻松绕过。第二个问题更隐蔽环境清理方案在子进程里清除了敏感密钥却通过/proc文件系统把它们完整地暴露给了父进程。换句话说密钥被藏在了孩子看不见的地方但家长随时能翻出来。把完整的Shell访问权限和唾手可得的凭证放在一起攻击路径就清晰了——从一个匿名Issue开始逐步升级到直接向主分支推送恶意代码。Google在自己的安全公告中给这个漏洞打出了CVSS 10.0的满分评级这是漏洞评分体系里的最高档意味着无需复杂条件就能造成完全破坏。作为回应Google对Gemini CLI的无头执行信任模型做了结构性重构不再默认信任运行环境。OpenAI Codex被忽视的AGENTS.md成了持久化后门OpenAI的Codex工作流设计了一个看似周全的隔离机制在同一个工作空间里运行两个代理实例彼此监督。敏感目录如.git和.codex被明确保护起来防止篡改。但安全团队漏掉了一个细节——AGENTS.md这个文件是代理每次启动时自动加载并信任的默认指令源。Meged的第一次攻击并不直接执行恶意代码而是悄悄修改AGENTS.md的内容。等到第二次安全的运行时代理会继承第一次留下的恶意指令连同文件中附带的任何提升权限或访问令牌一并接纳。这种持久化劫持的可怕之处在于它完全绕过了常规的单次运行安全检查——每一次独立的执行看起来都是干净的但累积效应却打开了一扇长期敞开的后门。OpenAI在三天内修复了自家仓库的代码把两次迭代拆分成独立的任务空间。但Meged警告说这种多迭代代理的架构模式已经被大量第三方项目复制底层的劫持风险远未消除。风险远不止这三家百余仓库存在同类隐患跳出这三家头部厂商的圈子Meged在测试的公共仓库中发现了超过一百个存在类似脆弱默认配置的项目。这意味着任何在自动化流程中部署AI编码代理的组织都可能不知不觉地继承了同样的攻击面。问题不是某个团队配错了参数而是整个生态在快速迭代中把安全假设当成了安全现实。Novee Security在报告中特别强调这些漏洞并非简单的配置失误或管理员疏忽。恰恰相反它们大多是经过深思熟虑的安全决策只是在系统不同模块的交接处出现了逻辑断层。一个模块做了正确的权限限制另一个模块做了合理的环境清理但两者对接时产生的盲区恰好给了攻击者可乘之机。给开发者的安全建议把AI代理当作不可信输入源面对这种新型威胁模型传统的边界防御思路已经不够用了。Meged给出的核心建议可以概括为一句话把AI代理工作流写入的每一个文件、读取的每一个数据源都视为不可信输入而不是默认相信供应商提供的安全开箱即用承诺。具体落地时团队可以考虑几个方向。首先在CI/CD管道中为AI代理设置最小权限原则即使代理被劫持能造成的破坏也被限制在可控范围内。其次对代理生成的每一次提交、每一个文件变更引入人工审查节点尤其是在涉及密钥文件或核心配置时。第三定期审计代理的默认指令文件和运行环境防止持久化后门的悄然植入。最后关注供应商的安全公告和CVE更新在补丁发布后尽快验证自身环境是否受影响。AI编码代理正在重塑软件开发的效率曲线但效率的提升不能以安全基线的崩塌为代价。当代理的权限越来越大、自主性越来越高时给它们套上同样级别甚至更严格的约束才是可持续的前进方式
返回列表