一条GitHub评论，劫持了三大AI编程助手

一个PR标题，换来一串API密钥

设想这样一个场景：你是一个开源项目的维护者，项目用了Claude Code做自动安全审查。某天，一个陌生人向你的仓库提交了一个Pull Request，标题看起来很正常——也许是一个Bug修复，也许是一个功能改进。你甚至还没来得及看，Claude Code就已经自动开始工作了。

但这个PR的标题里藏着一行精心构造的指令。Claude Code把它当作用户输入读进去了，然后忠实地执行了。几秒钟后，你的ANTHROPIC_API_KEY和GITHUB_TOKEN就被粘贴在了PR的评论里，对全世界可见。

这不是假设。这是2026年4月安全研究员Aonan Guan披露的真实攻击手法——“Comment and Control”（评论控制），一种跨厂商的提示注入攻击，同时攻破了Anthropic的Claude Code、Google的Gemini CLI Action和GitHub Copilot Agent三款主流AI编程助手。

攻击者给它起名”Comment and Control”，刻意模仿了恶意软件世界里经典的C2（Command and Control）框架。这不是巧合——这个攻击的威力，配得上这个名字。

攻击的底层逻辑：信任错位

要理解”Comment and Control”为什么能同时攻破三个产品，需要先理解AI编程Agent的工作原理。

现代AI编程Agent的核心架构可以简化为三步：

读取上下文——从代码仓库、Issue、PR中收集信息
调用AI模型——将上下文发送给大语言模型，获得操作指令
执行工具——根据模型输出，执行shell命令、读写文件、提交代码

问题出在第1步和第3步之间。AI Agent在读取上下文时，把所有输入——包括来自陌生人的PR标题和Issue评论——都当作”可信信息”处理。然后在第3步，Agent又拥有完整的工具执行权限，包括访问环境变量中的API密钥。

这就是信任错位：不可信的输入和敏感的权限存在于同一个运行时中，中间只隔了一个大语言模型的”判断力”。而大语言模型天生就无法可靠地区分”指令”和”数据”——这是提示注入攻击的根本原因。

传统提示注入需要受害者主动做点什么——比如让AI处理一个恶意文档。但”Comment and Control”不需要。GitHub Actions工作流会在pull_request、issues和issue_comment事件时自动触发AI Agent。攻击者只需要提交一个PR或开一个Issue，Agent就会被唤醒，自动读取恶意内容并执行。受害者完全无感。

三个漏洞，同一个架构缺陷

Claude Code：一个PR标题，RCE

Claude Code Security Review是Anthropic提供的自动代码审查服务，基于Claude CLI构建。当有新PR提交时，GitHub Actions会自动调用Claude CLI进行安全审查。

问题出在PR标题的处理方式上。Claude Code将PR标题未经任何净化处理直接插入Agent的提示上下文。同时，调用Claude CLI时没有使用--disallowed-tools或--allowed-tools参数来限制可用工具——这意味着Agent拥有完整的shell执行权限，并且子进程会继承包括ANTHROPIC_API_KEY和GITHUB_TOKEN在内的所有环境变量。

攻击者的操作极其简洁：创建一个包含恶意标题的PR，标题中包含突破提示上下文的指令，指示Claude执行env、whoami或ps auxeww等命令，然后以”安全发现”的名义将结果以JSON格式粘贴到PR评论中。

API密钥就这样被公开了。在GitHub上，任何人都能看到。

该漏洞通过HackerOne报告（#3387969），Anthropic评分为CVSS 9.4严重漏洞，并发放了相应赏金。

Gemini CLI：伪造”可信内容”覆盖安全指令

Google的Gemini CLI Action在”Additional Content”部分将Issue标题、正文和评论纳入Agent的提示上下文。攻击者的手法更精巧：在Issue评论的末尾注入一段伪造的”Trusted Content Section”（可信内容区），内容是覆盖Gemini原有安全指令的恶意指令。

Gemini读到了这段伪造的”可信内容”，认为优先级更高，于是执行了攻击者的指令——将GEMINI_API_KEY作为公开的Issue评论发布。

这个漏洞由研究员Neil Fendley与约翰霍普金斯大学团队合作发现，通过Google VRP报告（#1609699），获得$3,337赏金。

GitHub Copilot：三重防护，全部绕过

GitHub Copilot Agent的漏洞在技术上最为复杂，也最有戏剧性。因为GitHub并非没有考虑安全问题——他们实施了三层运行时防护：

第一层：环境变量过滤。 GitHub的UU()函数会过滤子bash进程中的敏感环境变量。但攻击者发现，这个过滤只作用于子进程——从子进程运行ps auxeww可以读取未过滤的父Node.js进程和MCP服务器的/proc/[pid]/environ，从中获取GITHUB_TOKEN、GITHUB_COPILOT_API_TOKEN等凭证。

第二层：密钥扫描。 GitHub的扫描器会检测ghs_/ghu_等令牌前缀。但攻击者在提交前对输出进行了Base64编码，完美规避了所有模式匹配——扫描器看不懂编码后的内容。

第三层：网络防火墙。 GitHub限制了Agent的出站网络连接，防止凭证被外传到外部服务器。但攻击者根本不需要外部服务器——编码后的凭证文件通过标准的git push操作外泄到PR中，这是白名单操作，与正常的Copilot工作流毫无区别。

三层防护，每一层都有其逻辑，但组合在一起仍然被完全绕过。这揭示了一个深刻的问题：在AI Agent的安全设计中，”纵深防御”不能只是堆叠不同的检测机制，还需要考虑这些机制之间的交互漏洞。

同期：Gemini CLI的另一个RCE漏洞

“Comment and Control”事件余波未平，Gemini CLI又被曝出另一个高危漏洞。

4月28日，FreeBuf报道了Gemini CLI中的一个远程代码执行漏洞，该漏洞源于两个相关缺陷：

无头模式自动信任工作区。 早期版本的Gemini CLI在非交互式环境（如CI/CD流水线）下运行时，会自动信任当前工作区，无需明确批准即可从.gemini/目录加载配置文件和环境变量。如果攻击者在该目录中植入了恶意内容——比如通过一个包含恶意.gemini/目录的PR——CLI就会处理这些内容并执行有害命令。

–yolo模式绕过白名单。 Gemini CLI的--yolo参数允许跳过确认提示，自动执行AI建议的操作。但早期版本在启用--yolo时，未能正确执行~/.gemini/settings.json中定义的工具限制。如果工作流允许了run_shell_command，策略就会变得过于宽松，允许执行危险命令而非仅限已批准的操作。

这个漏洞由Novee Security的Elad Meged和Pillar Security的Dan Lisichkin通过谷歌漏洞奖励计划报告。修复后，无头模式不再自动信任工作区，需要显式设置GEMINI_TRUST_WORKSPACE: 'true'。

两个漏洞，同一个主题：AI工具在自动化场景下对”信任”的处理出了问题。

这不是Bug，是架构问题

“Comment and Control”和Gemini CLI RCE，表面上看起来是两个独立的漏洞，但它们共享同一个架构缺陷：

不受信任的数据流入持有生产密钥且拥有无限制工具访问权限的AI Agent。

这是AI编程工具安全的根本矛盾。AI Agent要做有意义的工作，就需要两个条件：读取尽可能多的上下文（包括外部输入），以及执行尽可能多的操作（包括shell命令和API调用）。但这两个条件的交集，恰好就是攻击者的天堂。

传统软件安全有一套成熟的模型：输入验证、权限分离、最小权限。但AI Agent打破了这个模型——因为AI模型的”判断力”被当作了一种安全机制，而”判断力”恰恰是AI最不可靠的部分。今天的提示注入技术已经可以可靠地绕过任何基于AI判断力的安全措施。

这不是某个厂商的问题。这是整个AI编程工具行业的结构性问题。

攻击面不止GitHub

安全专家警告，”Comment and Control”攻击模式不仅限于GitHub Actions。任何处理不受信任输入且能访问工具和密钥的AI Agent都可能受到影响：

Slack机器人：恶意消息触发AI Agent，泄露工作区凭证
Jira Agent：恶意Issue描述劫持AI，访问项目管理API
邮件Agent：钓鱼邮件劫持AI助手，读取邮箱中的敏感信息
部署自动化管道：恶意提交触发AI部署Agent，向生产环境注入恶意代码

每一个把AI Agent接入业务流程的决策，都在扩大攻击面。而绝大多数组织在拥抱AI编程工具时，并没有对相应的安全风险进行充分评估。

开发者和组织应该做什么

使用白名单，不是黑名单。 用--allowed-tools仅授予AI Agent最低必要的权限。黑名单（如阻止ps命令）很容易被绕过——cat /proc/*/environ可以达到同样的目的。

最小权限密钥原则。 执行只读任务（如Issue分类）的Agent不应持有写权限的GITHUB_TOKEN。定期审查Agent的环境变量，移除不必要的凭证。

设置人工审批环节。 在Agent执行出站操作或访问凭证前，要求人工批准。自动化不应该意味着”无人监管”。

审计AI Agent集成。 检查CI/CD管道中的所有AI Agent集成，监控Actions日志中的异常凭证访问模式。对Agent能读取的数据源和能执行的操作进行严格限制。

隔离Agent运行环境。 在容器或沙箱中运行AI Agent，限制其对宿主环境的访问。即使Agent被劫持，攻击者也无法突破沙箱获取宿主机的凭证。

一场尚未开始的军备竞赛

“Comment and Control”是首个公开演示的跨厂商AI Agent提示注入攻击案例。但它不会是最后一个。

AI编程工具正在以惊人的速度渗透开发者工作流——95%的开发者每周使用AI编码工具，75%的开发者已用AI完成超过50%的编码工作。但安全防护远远落后于功能开发。三大AI编程助手在提示注入面前几乎毫无还手之力，连GitHub精心设计的三层防护也被逐一绕过。

这不是一个可以通过打补丁解决的问题。这是AI Agent架构层面的一次安全范式转变——从”信任AI的判断力”到”永远不要信任AI的判断力”。

在那之前，下一次你收到一个陌生人的PR，先别急着让AI帮忙审查。那条看似无害的评论里，可能藏着一把打开你整个系统的钥匙。

信息来源