GitLost：我们诱骗GitHub的AI代理泄露私有仓库

# GitLost：我们如何欺骗 GitHub 的 AI 代理泄露私有仓库 - Noma Security 来源：https://noma.security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos/ **摘要**：Noma Labs 发现 GitHub 新推出的 Agentic 工作流中存在一个严重的提示注入漏洞，未经身份验证的攻击者只需在一个属于私有仓库所在组织的公共仓库中提交精心构造的 Issue，就能静默拉取私有仓库中的数据。Noma Labs 将该漏洞命名为 GitLost。 https://noma.security/wp-content/uploads/GitLost-full-video-1.mp4 ## 引言 GitHub 最近推出了 GitHub Agentic 工作流，将 GitHub Actions（GitHub 的自动化系统，用于响应仓库事件执行任务）与由 Claude 或 GitHub Copilot 驱动的 AI 代理相结合。GitHub Agentic 工作流允许团队用纯 Markdown 编写工作流，GitHub 代理会自动读取 Issue、调用工具并自主响应。作为一名具有安全开发背景的漏洞研究员，这一发布后我首先想到的问题既基础又直接：当 GitHub 代理读取了它不该信任的内容时，会发生什么？ 答案是教科书式的间接提示注入攻击——一种能静默将私有数据发送给互联网上任何人的攻击。提示注入是一类攻击手段，攻击者将恶意指令隐藏在 AI 代理读取的内容中，导致代理遵循这些隐藏指令，而非操作者本意的指令。 ## 什么是 GitHub Agentic 工作流？ GitHub Agentic 工作流让团队能够使用自然语言自动操作代码仓库。工作流以 Markdown（.md）文件形式存在，编译为 YAML（一种常见的配置文件格式）扩展名为 .yml 的 Actions 文件，并在具有可配置权限的 AI 代理帮助下运行。GitHub 代理可以读取 Issue、调用工具，并访问组织内的其他仓库。 ## GitLost 漏洞概述 GitLost 漏洞的根本原因，在当前的代理 AI 系统中已屡见不鲜：提示注入。在大多数代理提示注入攻击中，代理将错误内容视为可信指令源，允许自己被误导或滥用。这种情况发生在系统未能对系统级指令和不可信用户数据保持严格的信任边界时。在此特定案例中，任何恶意攻击者都可以创建一个 GitHub Issue，并在 Issue 正文中以纯英文隐藏命令，而 GitHub 的代理会遵循这些命令。 Noma Labs 发现的易受攻击的 GitHub Agentic 工作流配置如下： - 在 `issues.assigned` 事件触发工作流 - 读取 Issue 的**标题**和**正文** - 使用 `add-comment` 工具发布评论作为响应 - 对组织内的其他仓库（公共和私有）拥有读取权限 要利用此漏洞，攻击者无需任何编码技能、访问权限或凭据。只需在一个使用 GitHub Agentic 工作流设置的组织所属的公共仓库中打开一个 Issue，然后等待即可。 ## 攻击流程 让我们来看一下 Noma Labs 漏洞研究人员成功实施的确切攻击流程：首先，他们构建了一个看似完全无害的 GitHub Issue，看起来像是一位销售副总裁与客户会面后提出的合理请求，如下所示： ***在此特定示例中，工作流操作在 Issue 被分配时触发***，但我们的测试证实，它对其他 GitHub 工作流操作同样有效。 然后，在 GitHub 自动化分配了 Issue 之后，一个事件触发的工作流导致代理从 poc（公共）和 testlocal（私有）仓库获取 README.md 的内容。最后，GitHub 代理将其作为公共评论发布在公共仓库的 Issue 中，任何人都可以访问和阅读。 ## “附加”利用 GitHub 设置了限制性防护措施来防止这种情况发生，但它们未能按预期保护仓库。通过反复用不同变体测试 GitHub（正如攻击者所为），并添加关键词 **“另外（Additionally）”**，触发了模型的非预期行为，使其重新组织输出而非拒绝。本质上，通过欺骗模型，我能够确保 GitHub 的防护措施无法按预期工作，从而未能阻止数据泄露。 https://noma.security/wp-content/uploads/github_agentic_workflows.mp4 ## 漏洞概念验证 为完全透明起见，Noma Labs 确认的发现（包括我们的工作流复现和实时证据）可在此处找到： - **工作流运行**：https://github.com/sasinomalabs/poc/actions/runs/23909666039 - **Issue**：https://github.com/sasinomalabs/poc/issues/153 泄露的数据包括来自以下仓库的 `README.md` 内容： - sasinomalabs/poc（公共仓库） - sasinomalabs/remote-ping（公共仓库，确认无 README） - sasinomalabs/testlocal（私有仓库） ## 为何重要 GitLost 完美展示了每个组织在使用代理 AI 系统时面临的基本安全挑战之一。代理的上下文窗口同时也是其攻击面。代理读取的任何内容——无论是 Issue、PR、评论还是文件——如果代理将其视为指令输入，都可能被武器化。 传统安全模型通常假设信任边界由代码强制执行。而在代理系统中，信任边界部分由模型的行为强制执行，而模型本质上倾向于遵循指令。提示注入攻击对于代理 AI 来说，已经变得相当于 SQL 注入对于 Web 应用：一种系统性的、跨类别的漏洞类型，需要同样系统性的策略和防御措施。 ## Noma 对构建者/AI 安全负责人的建议 - 绝不要将用户控制的内容视为 AI 代理的可信指令输入 - 将权限限制在最小必要范围。具有跨仓库访问权限的代理尤其属于高价值目标 - 限制任何代理可以公开发布的内容，尤其是在响应 Issue 内容时 - 在将用户输入传递给模型之前，对其进行清理或将其与指令上下文隔离 ## 负责任的披露 GitLost 已以负责任的方式向 GitHub 披露。漏洞详情在 GitHub 知情的情况下在此分享。 *觉得有趣？订阅 Noma Labs 的更多代理 AI 漏洞研究，或查看：*[GrafanaGhost](https://noma.security/blog/grafana-ghost/)、[DockerDash](https://noma.security/noma-labs/dockerdash/)、[Context Crush](https://noma.security/blog/contextcrush-context7-the-mcp-server-vulnerability/)、[GeminiJack](https://noma.security/noma-labs/geminijack/)。*正在寻找有效的 Agentic AI 安全解决方案？联系我们[安排演示](https://noma.security/lp/demo/)，了解 Noma 的全面解决方案。*