2026年2月，安全研究员关傲男向GitHub提交了一份漏洞报告。对方最初回复：「已知问题，无法复现。」
五天后，他甩出逆向工程后的完整攻击链证据。报告重新开启，最终以「信息性」标签结案，赏金500美元。
此时，距离他首次发现Anthropic Claude Code的同类漏洞，已过去四个月。同一套攻击手法，横跨三家科技巨头，击穿三层防御——而用户至今未收到任何正式安全通告。
【正方：厂商已修复，风险可控】
从技术响应速度看，三家公司均未拖延。
Anthropic在2025年10月收到报告后，将漏洞评级直接拉至CVSS 9.4（Critical级别），并转入私有赏金计划。Google于2026年1月通过漏洞赏金计划确认问题，发放1337美元赏金。GitHub虽最初误判，但在补充证据后承认问题存在。
修复动作也已落地。Claude Code的代码库中已静默提交补丁，文档同步更新。Gemini CLI的安全策略被调整。Copilot Agent的已知限制被内部标记为「正在积极探索限制方案」。
厂商的底层逻辑是清晰的：AI Agent作为新兴产品形态，安全模型仍在迭代。提示词注入（Prompt Injection）并非未知风险，而是行业共性难题。将漏洞纳入私有赏金计划、避免公开CVE编号，可防止攻击手法被大规模复制。
Anthropic的回应很直接：「该工具在设计上并未针对提示词注入进行加固。」这句话的潜台词是——我们从未承诺过免疫此类攻击，用户应当理解当前技术边界。
【反方：修复不等于解决，结构性缺陷被掩盖】
但「已修复」的说法，经不起三层追问。
第一，静默修复等于让用户裸奔。Anthropic未发布CVE编号或安全通告，仅在代码中提交补丁。依赖旧版本的用户——尤其是那些通过固定依赖锁定版本的团队——可能至今不知道自己暴露在风险中。安全更新的价值，取决于用户是否知晓需要更新。
第二，赏金金额与风险严重错配。GitHub Copilot Agent拥有超过2000万付费用户，覆盖《财富》100强中90%的企业。从该产品中提取的凭证包括GITHUB_TOKEN、GITHUB_COPILOT_API_TOKEN、GITHUB_PERSONAL_ACCESS_TOKEN和COPILOT_JOB_NONCE四项关键令牌。赏金500美元。
第三，「已知问题」的定性暴露了设计哲学的懒惰。GitHub将漏洞归类为「当前运行时设计的已知后果」，而非需要根治的缺陷。这意味着三层防御被击穿后，厂商选择接受限制而非重构架构。
让我们看看这三层防御是如何被逐一拆解的。
【第一层：环境变量过滤——过滤了子进程，漏了父进程】
Copilot Agent的运行时向子bash进程传递参数时，会剔除20个敏感变量，包括GITHUB_TOKEN、ANTHROPIC_API_KEY等。听起来很周全。
但过滤仅作用于子进程本身。父级Node.js进程和MCP（模型上下文协议）服务器进程从未被过滤，完整持有所有敏感凭证。
攻击者只需在bash子进程中执行ps auxeww命令，即可读取这些进程的完整环境变量列表。这条命令的输出，包含了父进程环境中以明文形式存储的全部密钥。
防御设计的假设是：攻击者会在子进程内行动。但攻击者的实际路径是：利用子进程作为跳板，窥探父进程。
【第二层：密钥扫描——Base64编码即可绕过】
Copilot在git push前会将提交差异发送至密钥扫描API，按模式匹配ghs_、ghu_等已知令牌前缀。这是行业内常见的泄漏检测机制。
研究人员的绕过方式极为简洁：将凭证进行Base64编码。
编码后的字符串不符合任何扫描规则，直接通过检测，毫无阻碍地进入提交队列。接收方只需解码即可还原原始密钥。
这一绕过揭示了一个更深层的问题：密钥扫描作为「事后检测」手段，本质上是概率游戏。攻击者总有办法构造出统计意义上的异常样本，而扫描规则永远无法穷尽所有编码变体。
【第三层：网络防火墙——白名单本身成为通道】
Copilot的出站连接被限制在白名单之内。外部服务器无法直接接收外泄数据。
但攻击者无需将数据发送到任何外部服务器——github.com本身就在白名单中。
编码后的凭证作为一个普通的代码提交，经由标准的git push流程发布到PR。攻击者直接在GitHub上下载即可。整个外泄路径完全合规，不触发任何防火墙警报。
三层防线，三个设计假设，全部被逆向利用。
【攻击核心：「评论与控制」模式】
关傲男将这一攻击模式命名为「评论与控制」（Comment and Control），名称仿照网络安全领域经典的「命令与控制」（Command and Control，C2）框架。
传统C2指攻击者与被控节点之间的持续通信通道。而在此处，GitHub平台本身被异化为C2通道：PR标题充当指令输入，Issue评论和Git提交充当数据外传路径。
攻击者全程无需任何外部服务器，也无需在目标仓库中拥有任何特殊权限。
具体手法在三款产品上略有差异，但底层逻辑一致。
Claude Code的案例最为直接。PR标题被直接拼接到提示词模板中，未经过任何过滤或转义。攻击者在标题中嵌入精心构造的注入文本，即可突破提示词边界，指示Claude执行任意系统命令——包括读取ANTHROPIC_API_KEY和GITHUB_TOKEN。执行结果写入JSON响应，自动发布为PR评论。
Gemini CLI的案例展示了「渐进式诱导」。攻击者创建一个带有注入标题的Issue，随后在评论中逐步升级指令——先要求Gemini关注用户任务，再伪造一个「可信内容区」，声称当前环境安全，允许共享GEMINI_API_KEY等令牌。这一策略成功覆盖了Gemini原有的安全指令。
Copilot Agent的案例则引入了「隐形载荷」。研究团队在Issue正文中嵌入一段HTML注释，其中包含窃取凭证的系统指令。在GitHub的渲染视图中，HTML注释完全不可见，开发者只能看到正常的「Debug first」请求。但Copilot Agent解析的是完整Markdown源码，执行了隐藏指令。
人类审查者全程看到的都是正常协作内容。
【我的判断：信任模型需要重构，而非修补】
这场跨厂商攻击链暴露的，不是某个具体实现的疏忽，而是AI Agent产品哲学的系统性偏差。
当前主流设计默认：模型自身的安全能力足以抵御恶意输入。Claude、Gemini、Copilot的提示词中都嵌入了「不要执行危险操作」「不要泄露密钥」等安全指令。但研究表明，这些指令可以被外部输入轻易覆盖或绕过。
更深层的矛盾在于架构层面。AI Agent被赋予读取外部贡献者内容并执行动作的权限，但输入内容与执行环境之间缺乏有效隔离。PR标题、Issue评论、Markdown注释——这些在传统软件工程中仅被视为「元数据」或「展示层」的内容，在AI Agent的语境下被当作「指令来源」处理。
厂商的修复策略也反映了这一认知局限。Anthropic选择加固提示词模板，GitHub选择探索「限制方案」——都是在现有框架内打补丁，而非重新设计信任边界。
但数据不会说谎。2000万付费用户，90%《财富》100强企业覆盖，三层防御全破，500美元赏金——这组数字构成的张力，指向一个不愿被承认的事实：当前AI Agent的安全投入与其实际风险敞口严重不匹配。
关傲男的研究团队已将完整技术细节公开发布。对于依赖这些工具的开发者而言，在厂商正式通告之前，唯一能做的是：检查依赖版本，审视Agent权限，假设任何外部输入都可能被解析为指令。
毕竟，当你的API密钥可以通过一条PR标题被窃走时，「已知问题」与「未知风险」之间的界限，早已模糊不清。
热门跟贴