摘要：Invariant披露了一个影响广泛使用的GitHub MCP集成漏洞。该漏洞允许攻击者通过恶意GitHub Issue劫持用户代理，导致泄露其私有代码库中的数据。Invariant通过其自动安全扫描程序（MCP-Scan）发现该漏洞。利用该漏洞可以操纵代理会

Invariant披露了一个影响广泛使用的GitHub MCP集成漏洞。该漏洞允许攻击者通过恶意GitHub Issue劫持用户代理，导致泄露其私有代码库中的数据。Invariant通过其自动安全扫描程序（MCP-Scan）发现该漏洞。利用该漏洞可以操纵代理会执行非预期的操作，例如泄露隐私仓库数据甚至导致恶意代码执行。

此时提高对此问题的认识非常重要，因为业界正在竞相广泛部署编码代理和 IDE，这可能会使用户面临针对关键软件开发工具的类似攻击。

MCP是“Model Context Protocol”的缩写，翻译成中文即模型上下文协议。是大模型时代，作为大模型与现有系统直接交互通讯协议。MCP服务作为一个中枢将所有大模型和其他系统之间的桥梁，能够自动替代人类访问和操作这些外部工具，避免大模型与现有系统间的繁琐认证交互流程等。

如上图所示大模型通过客户端直接访问MCP服务。

MCP服务则能访问浏览器、文件系统等数据源，也可以执行一些特定操作。例如，读取和写入浏览器信息、处理本地文件、执行Git操作等。

MCP需要客户端的支持，目前支持MCP协议的工具Cline、Cursor、WindSurf，等上篇文章提到的一些AI编程工具以及Claude APP（MCP协议提出和开源厂商）。

GitHub MCP Server是由GitHub于今年五月初才开源的一款全新的MCP系统，旨在为大模型访问GitHub功能提供了一种标准化的方式，其主要功能包括：

自动化GitHub工作流和过程。

从GitHub仓库中提取和分析数据。

构建基于GitHub生态系统的AI应用。

此次暴露的漏洞出现在用户使用MCP客户端，成功连接到Github MCP服务器（使用其个人令牌）。 假设用户创建了两个存储库：

/public-repo：一个可公开访问的公有库，允许GitHub上的每个人创建问题和错误报告。

/private-repo：私有库，例如具有保密代码或用户私人数据。

根据标准的GitHub规则，攻击者可以在公共存储库上提一个恶意问题（ISSUE），其中包含等待代理交互的提示注入。

当GitHub帐户的用户和所有者请求查询其代理，就会触发实际攻击，例如查：看/public-repo，这将导致代理从公共存储库中获取问题并进行注入中之前提交的恶意问题。

如图所示，当代理执行到公有仓中攻击者创建的有特殊代码的GitHub问题时，GitHub MCP就会被迫请求私有存储库数据，并获取上下文，并将其泄露到公共存储库中自主创建的PR中，攻击者或任何其他人都可以浏览到这些信息。

演示

为了更具体地说明，Invariant使用一组演示存储库实际实现了这种攻击：

ukend0464/pacman：一个带有Pacman游戏简单实现的公共存储库。

多个私人存储库包含个人项目和有关用户的敏感信息。

在在公共存储库中提交一个进行制作的恶意问题，攻击者可以访问该问题。该问题包含一个有效载荷，代理程序在查询公共存储库的问题列表时将立即执行该载荷。

用户交互要触发攻击，用户只需向Claude 4 Opus发出以下请求：

然后，Claude使用GitHub MCP集成来执行这些指令。

在此过程中，Claude Desktop 默认要求用户确认每个工具调用。然而，一般用户在使用代理时已经选择了“始终允许”的确认策略。

攻击部署代理现在会遍历问题列表，直到找到攻击载荷。它会主动将私有存储库数据拉取到上下文中，并将其泄露到 pacmanrepo，由于它是公开的，因此攻击者可以自由访问。

该拉取请求包含以下新信息：

其中包括几条私人信息。利用该漏洞，最终成功获取了用户的ukend0464的私人存储库的信息，例如Jupiter_Star、ukend，甚至一些私人的个人信息。

这个攻击的流程中大模型代理和MCP之间的交互过程如下：

影响范围和缓解措施

漏洞复现中以Claude Desktop为例子，但根据原理该漏洞适用于任何特定代理或MCP客户端。它会影响任何使用GitHub MCP服务器代理，无论其底层模型或实现如何。

甚至，更重要的：

这并非GitHub MCP服务器代码本身的缺陷，而是一个必须在代理协议和系统层面解决的根本架构问题。GitHub无法独自通过服务器端补丁解决此漏洞。为此目前建议采取以下两种关键缓解策略来防止此类攻击并加强代理系统的安全态势。

使用GitHub等MCP集成时，务必遵循最小权限原则，将代理访问权限限制在需要交互的仓库。虽然传统的基于令牌的权限机制提供了一定的保护，但它们通常会施加严格的约束，限制代理的功能。

为了在不牺牲功能的情况下实现更有效的安全性，建议实施动态运行时安全层解决方案提供上下文感知的访问控制，可适应代理的工作流程，同时强制执行安全边界。通过该方法可以有效地限制了代理在每个会话中只能处理一个存储库，防止跨存储库信息泄露，同时在授权范围内保持完整的功能。

除了预防措施外，还要实施强大的监控解决方案，以实时检测并应对潜在的安全威胁。建议部署专业的安全扫描程序，例如Invariant的 MCP-scan ，以持续审核代理与MCP系统之间的交互。

实施全面监控还可以创建审计跟踪，有助于识别潜在漏洞、检测利用尝试并确保代理系统免受新兴攻击。

此次暴露的GitHub MCP服务器的严重漏洞，该漏洞允许攻击者通过恶意GitHub Issue劫持用户代理，并迫使其泄露私有代码库中的数据。

研究结果表明，即使是最先进的对齐模型也容易受到这些攻击。在实验中，使用了Claude 4 Opus，这是一个非常新近、高度对齐且安全的AI模型。尽管该模型经过了强大的安全训练，但仍然容易受到相对简单的即时注入攻击的操纵。同样，许多现成的即时注入检测器防御措施也无法检测到这种攻击。

漏洞之所以持续存在，是因为代理系统的安全性从根本上来说取决于上下文和环境。虽然通用的模型对齐训练可以创建一些防护措施，但它无法预测每个部署场景或组织环境的具体安全要求。安全措施必须在系统层面实施，以补充模型层面的安全保障措施。

来源：虫虫安全