9.6分的CVSS评分，距离满分只差0.4。这个数字在漏洞评级里属于"看到就要连夜修"的级别——而GitHub Copilot Chat的这个漏洞，让攻击者连一行恶意代码都不用写，就能把私有仓库的源代码、API密钥、云凭证全部抽走。
漏洞代号CamoLeak：一场"看不见"的数据劫持
2025年10月，安全研究员公开披露了名为CamoLeak的攻击手法。GitHub其实在8月已经通过禁用Copilot Chat的图片渲染功能完成了修复，但漏洞的运作机制足以让任何依赖AI辅助开发的团队后背发凉。
Copilot Chat的核心功能是审查拉取请求（Pull Request）。它会读取描述、代码和仓库文件，用的是开发者本人的权限。这个设计本身没问题——直到攻击者发现，GitHub的Markdown语法里藏着一种"隐形注释"。
这种注释在标准网页界面里完全不显示，人类评审员看到的只是普通的代码变更。但Copilot处理的是原始文本，它会直接把隐藏内容当成合法指令执行。打个比方：你给AI看一份合同，人类看到的是正文，AI却连页边空白处的铅笔小字都照单全收，还当成正式条款。
攻击分为四个阶段。第一步，攻击者在拉取请求的描述或评论里植入恶意提示，用Markdown注释语法包裹。第二步，Copilot Chat解析时触发这些指令，被诱导将敏感数据编码到图片URL中。第三步，数据通过GitHub的Camo图片代理服务外发——这是GitHub自己的可信基础设施。第四步，攻击者服务器收到嵌套在图片请求里的数据片段，像拼图一样还原出完整信息。
最精妙的设计在于对GitHub内容安全策略（CSP）的绕过。
CSP的本意是阻止页面加载外部不可信来源的图片，从而防止数据外泄。CamoLeak的应对策略是预计算GitHub Camo代理的有效签名地址字典——每个地址对应攻击者服务器上的一个透明1×1像素，同时代表一个编码后的字符。
由于流量走的是GitHub自家的可信通道，传统的网络出口监控根本识别不出异常。数据外泄看起来就像正常的图片加载，甚至不会触发常规的安全警报。
AI助手的"权限悖论"：越能干，越危险
CamoLeak的技术细节暴露了一个结构性问题。AI助手需要深度系统访问才能提供有价值的辅助——读代码、审文档、跨文件关联信息。但这种访问权限一旦被操纵，就成了最高效的渗透管道。
GitHub不是孤例。Microsoft 365 Copilot能读取企业邮件和文档，Google Gemini接入了Workspace生态，各类IDE插件更是直接扎根开发环境。只要存在"不可信内容影响AI指令流"的交互点，CamoLeak的攻击逻辑就能迁移。
传统安全架构在这里出现盲区。数据外泄走的是可信渠道，用的是合法权限，行为模式模仿正常业务操作。防火墙、DLP（数据防泄漏）系统、网络流量分析——这些基于"识别恶意"的防御层全部失效。
安全厂商的应对思路正在转向端点。BlackFog的ADX平台代表了一类新方案：不再追问"流量是否可疑"，而是直接监控设备的出站数据，无论发起方是攻击者还是被劫持的AI代理，敏感信息出境即拦截。
这种"零信任外泄"的逻辑，本质上是对AI时代攻击面的重新界定。
修复之后：被改变的安全假设
GitHub的修复方案是禁用Copilot Chat的图片渲染。这切断了攻击链的最后一环，但并未解决根本矛盾——AI助手仍在解析可能包含隐藏指令的文本，只是少了一个外泄通道。
对于开发团队而言，这个漏洞提出了一个实操层面的问题：当你的AI代码审查工具比人类评审员"看得更多"时，谁来审查AI看到的内容？拉取请求的Markdown描述、issue评论、文档更新——这些传统上被视为"低风险"的文本区域，现在都需要纳入威胁模型。
更深层的影响在于供应链信任。开源生态依赖大量自动化审查和AI辅助的代码分析，CamoLeak证明了这种依赖可以被逆向利用。攻击者不需要攻破仓库，只需要提交一个看似无害的拉取请求，让项目的AI助手"自愿"交出数据。
安全研究员在披露时指出，这类攻击的检测难度极高。没有恶意代码执行，没有异常进程启动，没有横向移动——只有一连串经过合法签名的图片请求，在日志里几乎不可见。
当AI助手成为开发流程的标准配置，安全团队是否准备好应对"权限即攻击面"的新现实？下一次漏洞，可能藏在哪个你从未检查过的文本角落？
热门跟贴