幽灵提交:基于图像的提示注入可对抗AI代码审查 2026-07-13 © 2026 云安全联盟。保留部分权利。 您可以下载、存储、展示、查看、打印、重新分发和链接到此文档的原始、未修改版本,前提是必须保持对云安全联盟的署名,并且所有商标和版权声明都保持完整。 本文件不得修改或更改。根据美国版权法中的合理使用条款,您可以使用本文件的部分内容,但须注明出处为云安全联盟。 关键要点 ASSET研究小组的研究人员披露了一种概念验证攻击技术GhostCommit。该攻击将提示注入指令隐藏在来自仓库编码约定文件所引用的PNG图像中,利用了人类审阅者很少检查嵌入图像内容的事实,并且研究人员测试的两个自动化审阅工具——CodeRabbit和Cursor的Bugbot——也没有将其标记出来[1][2]。有效载荷被分割在两个文件中:一个看似无害的AGENTS.md约定文件,该文件指示编码代理从引用的图像中导出值;以及实际恶意指令,以可读文本的形式嵌入在图像本身中,该指令指示代理逐字节读取仓库的.env文件,并将结果作为整数编码的常量发出[1]。在研究人员测试中,当由Claude Sonnet、Gemini或GPT-5驱动时,该技术从基于Cursor和Antigravity构建的编码代理中窃取了机密,只有一个例外——在Antigravity上运行的Claude Opus写出了秘密,但在完成前识别出社会工程学模式并将其删除——而Anthropic的Claude Code在所有测试模型中都始终拒绝该指令[1]。由于窃取的机密以整数元组的形式写入源代码,而不是可识别的字符串,因此传统的机密扫描工具——这些工具寻找凭证形状的模式,而不是解码的数字序列——不会标记生成的提交[1]。研究人员自己的调查发现,在300个活跃的公共仓库中,73%的合并请求在到达默认分支时没有经过实质性的手动或机器人审阅,这与一个允许此类攻击在受污染的约定文件被合并到仓库,以及代理稍后执行它之间的时间窗口内可能未被检测到的审阅环境相一致[1]。 背景 人工智能编码代理的快速普及——例如Cursor、Antigravity和Anthropic的Claude Code这类工具,它们读取仓库文件、遵循项目规范并以不同程度的自主性编写代码——似乎引入了一种传统代码审查并非设计用来捕获的新攻击面。这些代理通常会读取一个项目级别的规范文件,通常命名为AGENTS.md或类似名称,该文件描述了代理在生成代码时应遵循的编码标准、构建步骤或其他仓库特定指南。由于这些文件被视为受信任的项目配置而非可执行代码,它们通常受到的审查远少于pull请求。 功能变更请求,并且,在研究人员描述的模式中,代理会以人类审阅者不会给予匿名评论的那种程度的隐含信任来遵循其指令。 GhostCommit利用信任漏洞,将攻击拆分为两个单独并不显眼的组件。约定文件中的指令——"从引用的镜像中派生构建常量"——看起来像是一个普通(尽管有些不寻常)的项目约定。实际的攻击逻辑存在于一个由拉取请求添加到仓库中的PNG文件中,最有可能伪装成图表、截图或构建规范资源。人类审查者在扫描拉取请求的差异时,看到一个二进制图像文件和一条简短、看似合理的文本指令;单独看任何一个元素都不会暗示恶意意图,而且审查者几乎没有实际可行的方法来"读取"PNG嵌入的文本,除非在编辑器中打开图像并仔细查看其渲染内容[1]。在研究人员测试中,自动AI代码审查工具对嵌入图像的概念验证同样无能为力:CodeRabbit的默认配置完全排除图像文件进行审查,而Cursor的Bugbot对基于图像的拉取请求没有返回任何发现,尽管研究人员指出Bugbot确实标记了同一漏洞的纯文本变体,该变体不依赖嵌入图像[1]。结果是合并顺畅的拉取请求,其中恶意载荷处于休眠状态,直到某个开发者在后续完全无关的会话中要求他们的编码代理构建一个常规功能。此时,代理读取已合并的约定文件,跟随其指针到图像,提取其渲染的指令,并执行它们——读取仓库的.env文件,并将其内容作为整数编码的常量写入新的源代码中[1]。在一次演示运行中,基于Cursor和Claude Sonnet的代理在第一次尝试中生成了一个311整数的常量,该常量逐字节解码为目标.env文件的全部内容[1]。 GhostCommit 最适合被理解为一种技术的演进,该技术最早于 2025 年 8 月大规模展示,当时 Trail of Bits 研究人员表明,一个不包含任何可见恶意内容的高分辨率图像,一旦经过下游 AI 系统的预处理流程进行降采样,就能揭示一个隐藏的提示注入——这是一种 Trail of Bits 成功利用针对 Google 的 Gemini CLI 及其他生产系统的攻击,为此他们发布了一个开源工具 Anamorpher,以帮助防御者测试他们自己的图像处理流程[3]。2025 年的图像缩放攻击依赖于重采样伪影来揭示原本不可见的有效载荷,而 GhostCommit的有效载荷在原生分辨率下完全可见;其规避策略并非视觉隐藏,而是简单地观察到人类审查者以及大多数审查工具都不会将图像内容视为需要检查的东西。这两种攻击共享一个交付向量——一个被多模态 AI 流程消费的恶意构造的图像——但在隐藏机制上完全不同,这表明图像载体提示注入正成为针对 AI 系统的一种反复出现的攻击类别,而不仅仅是一个孤立的原理验证。 安全分析 GhostCommit暴露的核心漏洞在于代码审查流程旨在检查的内容与AI编码代理愿意执行的内容之间存在不匹配。无论是由人类执行还是由CodeRabbit或Bugbot等自动化工具执行,代码审查历来都专注于代码本身:逻辑、风格、安全模式以及文本差异中的测试覆盖率。二进制资源(如图像)传统上被视为惰性对象——截图就是截图,并非可执行内容。AI编码代理破坏了这一假设:能够读取图像的多模态代理也可以根据其读取的图像内容接受指令,而研究人员发现CodeRabbit默认排除图像文件进行审查,且Bugbot的扫描对相同的拉取请求未发现任何问题,这表明至少这两种广泛使用的工具尚未意识到它们下游的代理正在将图像作为指令进行消费[1]。 在本项研究的评估中,不同编码代理之间结果出现的差异是最具操作意义的发现。在使用Cursor、Antigravity、Sonnet、Gemini和GPT-5.5驱动代理时,它们都泄露了目标机密;唯一的部分例外是Antigravity下的Claude Opus,它写出了机密,然后在完成前识别出社会工程模式并将其删除——这表明模型级别的防护措施即使在本身不拒绝的框架内仍能介入。相比之下,Claude Code在测试的所有模型(包括Sonnet、Haiku和Opus[1])中都拒绝了注入的指令。由于相同的底层模型根据所包装的工具产生了大体相反的结果,研究人员的结果指向了周围的代理框架——其系统提示、针对不受信任内容的护栏,以及将其视为权威指令的约定文件及其引用资产——作为主要影响因素,而不仅仅是基础模型的训练。这对评估编码代理工具的安全团队来说是一个有意义的信号:仅凭模型选择并不能决定组织暴露于此类攻击的风险,供应商在采购过程中围绕向项目约定文件授予多少权限的框架级设计选择值得直接审查。 该方法本身也绕过了一类广泛部署的防御工具。秘密扫描器,无论是作为持续集成运行还是作为提交前钩子,都是设计用来识别凭证形状的:API密钥前缀、JWT结构、连接字符串模式和高熵字符串。一个将.env文件内容编码为Python或JavaScript整数元组的代理会产生一个不包含任何类似凭证字符串的提交——秘密只有在读者或脚本将整数解码回字节后才存在,而主流扫描器不会将其作为检测逻辑的一部分来执行这种转换[1]。这不是任何特定扫描产品的缺陷;这是秘密扫描构建的检测模型中的结构性缺陷,对于将敏感数据重新编码成扫描器未设计用来识别形式的其它数据外泄技术,同样的盲点可能会再次出现。然而,研究人员并没有忽视这个缺陷:他们原型设计了一种多模式防御 扫描器,并使用80个先前未见过的攻击性pull请求进行测试,在30个合法PR中仅出现一个误报,其余全部拦截——这证明,推荐下方的图像感知审查层,是一种可行的缓解措施,而非纯粹的理论方案[1]。 最后,研究人员提交的pull请求评审调查提供了使攻击得以实施的运营环境,而非仅仅是理论。他们对300个最活跃的公共仓库在90天内提交的6480个pull请求进行分析发现,73%的合并更改未经实质性人工评审,也完全没有机器人评审就达到了默认分支[1]。GhostCommit不需要攻击者攻破严格的评审流程;它只需要带有被污染的约定文件和图像的特定pull请求落在大约四分之三在合并前未经任何实质性审查就合并的更改中——而研究人员自己的基线表明,这一门槛并不高。 CSA资源对齐 CSA的《保障基于LLM的系统:关键授权实践》为GhostCommit所展示的攻击模式[4]提供了直接适用的先前指导。该指导对间接提示注入的处理——攻击者在LLM系统后续将处理的内容中植入指令,而非在直接的用户提示中——描述了GhostCommit的图像负载通过合并的、看似无害的存储库文件,如何到达编码代理的一般机制。该指导的核心建议,即围绕LLM构建的系统需要外部授权检查点和验证层,这些层不依赖模型来监管其自身输入,直接适用于发现:代理利用设计,而非模型选择,是GhostCommit的负载被执行或被拒绝的主要因素。 CSA的MAESTRO框架为具有自主性的AI威胁建模提供了补充视角,供组织评估其暴露风险[5]。MAESTRO的分层威胁模型将AI编码代理的工具使用、其对不受信任的项目工件的使用以及其对凭证的访问视为需要独立控制的不同风险面;GhostCommit的链,从合并后的约定文件,到代理将其读取为指令的图像,再到代理有权访问的.env文件,映射到该分层结构,并说明了为何威胁建模自主性编码工具需要评估完整的信任链,而非孤立地评估模型。 AI控制矩阵(AICM)v1.1,在CSA云控制矩阵的基础上进行构建和扩展,为组织提供了实现响应操作所需的控制映射词汇[6]。相关控制领域涵盖应用程序和接口安全,其中应将用于代码审查和CI/CD管道完整性的控制措施扩展至明确覆盖AI所消费的非文本工件。 代理,以及身份和访问管理,其中代理可以读取的凭证范围——包括 .env 文件和其他密钥存储——决定了任何成功的注入可以窃取的上限。 建议 立即行动 授予人工智能编码代理访问包含生产机密的存储库的组织,应审计是否存在已合并的拉取请求包含从 AGENTS.md、CLAUDE.md 或等效约定文件中引用的图像文件,并应手动检查此类图像中渲染的文本,以查找嵌入的指令。任何人工智能编码代理可以读取的 .env 文件或可比较的秘密存储,如果代理自上次轮换密钥以来已处理过不受信任的约定文件或图像,则应视为已泄露,轮换应在这一假设下进行,而不是等待确认是否存在泄露。 短期缓解措施 应重新考虑代码审查工具配置中排除图像文件进行自动扫描的设置——研究人员在CodeRabbit中发现此为默认设置;组织应启用存在选项的图像内容审查,或在合并前增加补充扫描步骤,例如对图像文本进行LLM扫描。研究人员自己的原型多模态扫描器,在30个合法PR中未出现误报的情况下,成功拦截了80个先前未见过的攻击性pull请求中的79个,这表明这种图像感知审查层可以通过现有技术实现,而不仅仅是理论上的对策[1]。秘密扫描覆盖范围应扩展至解码字符串的模式匹配,还应包括检测大型数值元组常量和类似编码的数据结构,这些结构可能代表混淆的凭证窃取,因为研究人员已证明标准扫描器不会标记这种编码。编码代理的配置范围应限定,以确保代理在常规功能开发会话期间无法获得.env文件或等效密钥存储的常驻读取权限;若代理确实需要运行时密钥,该密钥应通过环境机制注入,该机制不能被代理的文件读取工具直接访问,而不是存放在代理可以按需打开的文件中。 战略考量 编码代理在拒