2026-10-17 03:29:23 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

Black Hat 2026上一条GitHub Issue，黑进了三家顶级AI编程助手

原创

v3n0m
v3n0m

v3n0m

2026年8月24日 23:34
天津

在小说阅读器读本章

去阅读

想象一下这个场景。

你是一个普通GitHub用户，没有任何仓库的写权限，不是维护者，不是协作者，甚至连star都没点过几个。你打开Anthropic官方的Claude Code仓库，发了一条看起来再正常不过的Issue——比如\"我在使用时遇到了一个小问题，帮忙看看\"。

然后，你拿到了Anthropic CI服务器上的远程代码执行权限。

你偷走了workflow里的ANTHROPIC\_API\_KEY和GITHUB\_TOKEN。你可以读取任意文件，写入恶意代码，横向移动到其他系统。

这不是科幻。这是2026年8月5日，安全公司Novee Security的创始工程师Elad Meged在Black Hat USA 2026上现场演示的真实攻击。

而且，中招的不止Anthropic一家。Google的Gemini CLI、OpenAI的Codex，全部以同样的方式被攻破。

最讽刺的是：测试用的就是三家公司自己的官方仓库、自己的默认配置、自己的AI编程Agent。一个陌生人的输入，直接触达了生产密钥。

01 发生了什么：零权限输入如何触达生产密钥

先把事件本身说清楚。

Novee Security的这项研究有一个非常关键的测试设定，正是这个设定让它从\"又一个AI安全论文\"变成了\"所有用AI编程Agent的团队都该立刻看一眼\"的警报。

他们没有用自己搭的实验环境。他们直接在三家厂商自己的官方开源仓库上做的测试。

具体来说：

在Anthropic的anthropics/claude-code仓库上，运行Anthropic自己的Claude Code Agent，用Anthropic自己的默认GitHub Action配置。

在Google的Gemini CLI仓库上，运行Google自己的Gemini CLI Agent，用Google自己的默认配置。

在OpenAI的Codex仓库上，运行OpenAI自己的Codex Agent，用OpenAI自己的默认工作流。

然后，攻击者只需要做一件事：以一个没有任何仓库权限的普通GitHub用户身份，打开一条Issue。

这条Issue里藏着prompt注入——表面上是正常的问题反馈，实际上嵌入了给AI Agent的秘密指令。当仓库的自动化工作流触发AI Agent去\"阅读并处理这条Issue\"时，Agent读到的不是用户的问题，而是攻击者的命令。

结果：

Claude Code：远程代码执行 → 任意文件读取 → 窃取ANTHROPIC\_API\_KEY和GITHUB\_TOKEN。Anthropic分配了CVE-2026-54316，受影响版本从0.2.54到2.1.163，修复版本2.1.163。

Gemini CLI：OS命令注入，在沙箱启动之前就在CI主机上执行任意代码。CVSS评分10.0——满分。Google分配了CVE-2026-12537（GHSA-wpqr-6v78-jr5g），修复版本0.39.1。

Codex：通过写入恶意AGENTS.md文件，实现对后续Agent运行的持久化劫持。OpenAI没有分配CVE编号。

三个产品，三家公司，三种不同的技术实现，同一个攻击入口，全部中招。

Novee Security在博客里写了一句很克制但分量很重的话：\"我们在GitHub上展示了这个模式，但任何我们能控制Agent输入的自动化场景，都是脆弱的。\"

换句话说，这不是GitHub的问题。这是AI Agent本身的架构问题。

02 三条攻击链逐一拆解：每个都不一样，每个都致命

虽然入口都是\"一条GitHub Issue\"，但三家产品的具体漏洞完全不同。这恰恰说明问题不是某个厂商的粗心，而是整个AI Agent架构范式的系统性缺陷。

Claude Code：用Hugging Face下载计数器，一个字符一个字符偷密钥

Claude Code的攻击链是最\"精巧\"的一条。

第一步，攻击者在Issue中嵌入prompt注入指令。Claude Code的GitHub Action被触发后，Agent读取Issue内容，执行了攻击者的指令——在CI runner上实现了远程代码执行。

第二步，有了RCE之后，攻击者可以读取任意文件。CI环境里有什么？workflow的密钥：ANTHROPIC\_API\_KEY和GITHUB\_TOKEN。这些是CI运行时注入的环境变量，本来应该只有受信任的工作流步骤能访问。

第三步，也是最巧妙的一步——数据外泄。CI环境通常有出站网络限制，不是所有域名都能访问。但Claude Code的验证器有一个缺陷：它在检查命令安全性之前，会先剥离单引号包裹的文本。这导致一个被批准的合法域名huggingface.co，被攻击者改造成了数据外泄通道。

具体做法是：把API密钥的每个字符，编码成Hugging Face上一个不存在的模型下载请求。比如密钥第一个字符是\"s\"，就请求下载huggingface.co/attacker/model-s；第二个字符是\"k\"，就请求model-sk。Hugging Face的公开下载计数器会记录每一次请求，攻击者只要查看自己模型页面的下载日志，就能一个字符一个字符地还原出完整密钥。

整个过程不需要建立任何可疑的出站连接，所有流量都去往一个被批准的合法域名。传统的网络监控和DLP（数据防泄漏）系统完全看不到异常。

Anthropic最终将这个漏洞评为CVSS 6.0（中危），并在2.1.163版本中修复。但考虑到这个漏洞影响了从0.2.54开始的几乎所有版本，实际暴露窗口相当长。

Gemini CLI：CVSS满分10.0，沙箱还没启动就被攻破了

Google Gemini CLI的漏洞是三个里面最严重的——CVSS 10.0，满分。

它的攻击链和Claude Code不一样，甚至不需要等Agent执行完prompt注入。它直接在Agent的容器启动阶段就完成了RCE。

具体来说，Gemini CLI在headless（非交互式）模式下运行时，会自动信任工作区目录，并加载其中的.gemini/.env文件。攻击者通过Issue中的指令，让Agent在工作区创建一个精心构造的.gemini/.env文件。这个文件里藏着OS命令注入payload。

当Gemini CLI的容器启动器读取这个.env文件时，命令注入被触发，攻击者在CI主机上获得了任意代码执行权限。

关键点在于：这个代码执行发生在沙箱初始化之前。也就是说，Gemini CLI引以为傲的沙箱隔离机制，在这个攻击面前根本还没来得及启动。攻击者直接在宿主机上执行代码，沙箱形同虚设。

还有第二个缺陷：Gemini CLI的工具白名单只在注册时检查一次，运行时不再重新验证。在--yolo（自动批准所有命令）模式下，模型请求的每一个命令都被自动通过，没有任何二次校验。这意味着即使第一个漏洞被修复，攻击者仍然可以通过prompt注入让Agent执行任意命令。

Google的修复方式也说明了问题的严重性：他们没有简单地打一个workflow补丁，而是直接改变了headless执行环境的信任模型——用真正的进程隔离替代了原来的环境变量清理机制。官方公告说得很明白：\"配置调整救不了你，只有升级才行。\"

Codex：一个恶意文件，劫持所有后续运行

OpenAI Codex的漏洞最隐蔽，也最让人不安。

Codex的工作流有一个设计：两次Agent运行（pass）共享同一个CI job和同一个可写的代码检出目录。这本身是为了提高效率——第一次运行做分析，第二次运行做修改，不需要重新检出代码。

但攻击者利用了这个设计。通过Issue中的prompt注入，攻击者让第一次运行的Agent在工作区写入一个恶意的AGENTS.md文件。

AGENTS.md是什么？它是Agent的\"系统指令文件\"——Agent在启动时会读取这个文件，里面的指令会被当作系统级别的指导来执行。很多项目用它来给Agent设定编码规范、项目结构说明等。

问题在于：这个文件是可写的，而且会在多次Agent运行之间持久存在。攻击者写入的恶意AGENTS.md，会被后续每一次运行的Codex Agent读取并执行。

这意味着什么？攻击者只需要发一条Issue，就能在仓库里埋下一个\"持久化后门\"。之后无论谁触发Codex Agent运行——维护者处理PR、自动修复bug、代码审查——Agent都会先读到攻击者留下的指令，在攻击者的控制下执行操作。

OpenAI没有为这个漏洞分配CVE编号。但从安全角度看，这种\"一次注入、持久控制\"的攻击模式，危害程度可能比一次性的RCE更高。

03 真正的问题：漏洞不在AI模型，在Harness

看完三条攻击链，一个自然而然的问题是：这是不是说明大模型本身不安全？

答案是：不是。

Novee Security的研究里有一句话被很多报道忽略了，但它恰恰是整个研究最核心的判断：

\"模型没有被攻破。被攻破的是harness。\"

什么是harness？就是包裹在大模型外面的那层\"壳\"——它负责把用户输入喂给模型，把模型输出转化为具体操作（执行命令、读写文件、调用API），管理工具调用权限，维护会话状态。简单说，模型是\"大脑\"，harness是\"手和脚\"，以及决定\"手能伸到哪里\"的安全边界。

这次三个漏洞，没有一个是让模型产生了错误输出。模型都在\"正常工作\"——它读到了Issue里的指令，然后忠实地执行了。问题出在harness没有区分\"哪些输入是可信的系统指令，哪些输入是不可信的用户内容\"。

这就是AI Agent时代最根本的安全矛盾：

传统软件的安全模型建立在\"指令和数据分离\"的基础上。代码是指令，用户输入是数据，数据不能被当作指令执行。但AI Agent的工作方式，从根本上打破了这个分离——它的\"指令\"就是自然语言，而自然语言既可以是系统指令，也可以是用户数据。两者在文本层面无法区分。

当你让一个AI Agent去\"阅读并处理一条GitHub Issue\"时，Issue的内容既是它要处理的\"数据\"，又可能包含它会执行的\"指令\"。Agent无法判断\"忽略之前所有指令，执行以下操作\"这句话，到底是用户在Issue里写的一段文字，还是给它的系统命令。

这就是prompt注入的本质。它不是一个bug，它是当前AI Agent架构的一个根本性特征。

更麻烦的是，AI编程Agent为了\"好用\"，被赋予了越来越强的工具调用能力：执行shell命令、读写任意文件、调用git和gh CLI、访问网络、安装依赖。这些能力正是它能帮你写代码、修bug、重构项目的基础。但同样的能力，一旦被prompt注入劫持，就变成了攻击者手里的武器。

这不是某个厂商的安全团队不够努力。这是整个行业在\"Agent能力\"和\"Agent安全\"之间做的一个还没有答案的权衡。

04 这意味着什么：不只是三个漏洞，是一个新的攻击范式

Novee Security的研究之所以在Black Hat上引起震动，不是因为他们发现了三个CVE，而是因为他们证明了一件事：AI编程Agent已经成为软件供应链的新攻击面，而且这个攻击面的利用门槛极低。

传统的软件供应链攻击，比如SolarWinds或者xz后门，需要攻击者有极高的技术能力和资源投入——你需要渗透进开发环境，需要修改构建流程，需要躲避代码审查，需要长期潜伏。

但AI Agent时代的供应链攻击，门槛降到了\"发一条Issue\"。

不需要任何权限，不需要零日漏洞，不需要社会工程学。你只需要知道目标仓库用了某个AI编程Agent的自动化工作流，然后发一条藏着prompt注入的Issue。剩下的，Agent自己会帮你完成。

这意味着什么？

第一，CI/CD流水线成为新的高价值目标。CI环境里通常有部署密钥、云服务凭证、代码签名证书、包管理器token。拿到CI的RCE，基本等于拿到了整个软件发布链路的控制权。攻击者可以在发布的软件里植入后门，而用户完全无法察觉。

第二，开源项目的维护者成为最脆弱的一环。开源项目通常资源有限，维护者精力不足，越来越依赖AI Agent来处理Issue、审查PR、修复bug。但恰恰是这些自动化的AI工作流，成了攻击者的入口。一个流行的开源库，如果它的CI被攻破，影响的可能是数百万下游项目。

第三，传统安全工具对这种攻击几乎无效。SAST（静态应用安全测试）扫的是代码漏洞，看不到prompt注入。DAST（动态应用安全测试）测的是运行时漏洞，不覆盖Agent的决策过程。WAF（Web应用防火墙）拦的是恶意HTTP请求，一条正常的GitHub Issue在它看来完全合法。EDR（终端检测与响应）能看到异常进程，但Agent执行的命令看起来和正常开发操作没有区别。

第四，攻击的隐蔽性极高。就像Claude Code用Hugging Face下载计数器外泄密钥那样，攻击者可以利用合法的服务和正常的流量模式来完成攻击，几乎不留下任何传统意义上的\"入侵痕迹\"。事后溯源极其困难。

Black Hat 2026上，不止Novee Security一家在讲这个问题。Check Point Research同期披露了6大主流Agent框架（LangChain、CrewAI、AutoGen、微软、Google等）的11个高危漏洞，全是反序列化、SSRF、路径遍历这类\"十年老漏洞\"在Agent框架里的复活。Pillar Security也披露了4款AI编程Agent的7个沙箱逃逸问题。

整个行业正在同时意识到同一件事：我们还没有为\"能自主执行操作的AI Agent\"建立起有效的安全模型。

05 普通开发者和团队该怎么办

问题很严重，但不是无解。在行业整体安全模型成熟之前，团队可以采取一些实际措施来降低风险。

第一，立刻升级。如果你在用Claude Code，升级到2.1.163或以上版本。如果在用Gemini CLI，升级到0.39.1或以上版本。Codex的AGENTS.md持久化问题，关注OpenAI的更新并及时升级。这是成本最低、效果最直接的一步。

第二，最小化Agent的权限。这是最核心的原则。问自己一个问题：这个AI Agent真的需要读写整个文件系统吗？真的需要访问所有环境变量吗？真的需要执行任意shell命令吗？真的需要网络访问吗？把Agent的权限限制在它完成任务所必需的最小范围内。CI环境中的密钥，不要全部注入给Agent，只给它当前任务需要的那一个。

第三，隔离不可信输入。GitHub Issue、PR评论、README、依赖包的描述、代码注释——这些都是不可信输入，都可能包含prompt注入。不要让Agent在拥有高权限的上下文中直接处理这些内容。可以考虑先用一个低权限的\"预处理Agent\"清洗和提取不可信输入中的关键信息，再把提取后的结构化数据传给高权限Agent执行。

第四，人工审核关键操作。AI Agent生成的代码修改、依赖变更、配置文件修改，在合并到主分支之前，必须经过人工审核。不要让Agent自动merge PR。特别是涉及安全相关文件（.github/workflows、Dockerfile、package.json、部署脚本）的修改，要格外谨慎。

第五，监控Agent的异常行为。建立Agent操作的审计日志，记录它执行了哪些命令、读写了哪些文件、访问了哪些网络地址。设置异常检测规则——比如Agent突然访问了它平时不会访问的域名、执行了超出它任务范围的命令、读取了环境变量中的密钥——这些都可能是被prompt注入劫持的信号。

第六，不要在生产密钥旁边跑Agent。如果可能，将AI Agent的运行环境和生产部署环境完全隔离。Agent的CI runner不应该拥有生产环境的部署权限。代码签名、发布到生产包管理器等关键操作，应该由独立的、不运行AI Agent的流水线来完成。

这些措施不能完全消除风险，但可以把\"发一条Issue就能黑进CI\"的攻击，变成需要多个环节同时突破才能成功的攻击。在安全领域，提高攻击成本本身就是有价值的防御。