# GitLost：Noma Labs 发现 GitHub AI 代理提示词注入漏洞

- 来源：Hacker News 热门（buzzing.cc 中文翻译）
- 作者：ColinEberhardt
- 发布时间：2026-07-08 16:29
- AIHOT 分数：81
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmrbu023x079pihl1q4rvhzky
- 原文链接：https://noma.security/blog/gitlost-how-we-tricked-githubs-ai-agent-into-leaking-private-repos

## 精选理由

GitLost 是第一个有完整复现的 GitHub AI 代理泄露私有仓库漏洞，展示了 AI 代理的上下文窗口即攻击面，做 AI 应用或 CI/CD 的人都该看一下。

## AI 摘要

Noma Labs 在 GitHub Agentic Workflows 中发现严重提示词注入漏洞 GitLost。未认证攻击者仅需在属于同一组织的公共仓库中创建一个嵌有恶意指令的 Issue，即可诱使基于 Claude 或 GitHub Copilot 的 AI 代理读取并公开该组织内私有仓库的内容。攻击无需编码技能或凭证，根源在于代理将用户可控内容视为可信指令，且 GitHub 的防护措施因 "Additionally" 关键词被绕过。Noma Labs 已公开 PoC 并建议限制跨仓库权限、隔离用户输入。

## 正文

GitLost：我们如何欺骗 GitHub 的 AI 智能体泄露私有仓库

Sasi Levi

2026 年 7 月 6 日

摘要：Noma Labs 发现 GitHub 新的智能体工作流中存在一个严重的提示词注入漏洞，允许未经身份验证的攻击者通过在属于与私有仓库相同组织的公共仓库中发布精心构造的 GitHub Issue，静默地从私有仓库中拉取数据。Noma Labs 将该漏洞命名为 GitLost。

引言

GitHub 最近推出了 GitHub 智能体工作流，将 GitHub Actions（GitHub 的自动化系统，用于响应仓库事件执行任务）与基于 Claude 或 GitHub Copilot 的 AI 智能体相结合。GitHub 智能体工作流允许团队用纯 Markdown 编写其 GitHub 工作流，而 GitHub 智能体会自行读取 Issue、调用工具并做出响应。作为一名具有安全开发背景的漏洞研究员，此次发布后我脑海中浮现的首要问题既基本又直接：当 GitHub 智能体读取了它不应信任的内容时，会发生什么？

答案是教科书式的间接提示词注入攻击，这种攻击会悄悄地将私有数据发送给互联网上的任何人。提示词注入是一类攻击，攻击者将恶意指令隐藏在 AI 智能体读取的内容中。这些内容会导致智能体遵循那些隐藏指令，而非操作者原本的意图。

什么是 GitHub 智能体工作流？

GitHub 智能体工作流让团队能够使用自然语言自动化其与代码仓库的交互。工作流存在于 Markdown (.md) 文件中，被编译为 YAML（一种常见的配置文件格式）、扩展名为 .yml 的 Actions 文件，并在具有可配置权限的 AI 智能体辅助下运行。GitHub 智能体可以读取 Issue、调用工具以及访问组织内的其他仓库。

GitLost 漏洞概述

如今，GitLost 漏洞的根本原因在智能体 AI 系统中已相当常见：提示词注入。在大多数智能体提示词注入攻击中，智能体会将错误的内容视为可信的指令来源，并允许自己被误导或滥用。当系统未能严格区分系统级指令与不可信用户数据之间的信任边界时，就会发生这种情况。在这个具体案例中，任何恶意行为者都可以创建一个 GitHub Issue，并在 Issue 正文中，用通俗易懂的英文隐藏命令，而 GitHub 的智能体会执行这些命令。

Noma Labs 发现的存在漏洞的 GitHub 智能体工作流被配置为：

在 GitHub 中触发 `issues.assigned` 事件上的工作流

读取 Issue 的标题和正文

使用 `add-comment` 工具发布评论作为响应

以对组织内其他仓库（公开和私有）的读取权限运行

要利用此漏洞，攻击者无需任何编码技能、访问权限或凭证。只需在使用 GitHub 智能体工作流设置的组织的公开仓库中创建一个 Issue，然后等待即可。

攻击流程

让我们看看 Noma Labs 漏洞研究人员成功实施的具体攻击流程：首先，他们精心制作了一个看起来完全无害的 GitHub Issue，内容是一位销售副总裁在与客户会面后提出的看似合理的请求，如下所示：

在这个具体示例中，工作流操作在 Issue 被分配时触发，但我们的测试证实，它对其他 GitHub 工作流操作同样有效。

然后，在 GitHub 自动化分配了该 Issue 后，一个事件触发的工作流导致智能体从 `poc`（公开）和 `testlocal`（私有）两个仓库中获取 `README.md` 文件的内容。最后，GitHub 智能体将这些内容作为公开评论发布在公开仓库的 Issue 中，任何人都可以访问和阅读。

“附加”利用方式

GitHub 设置了严格的防护措施来防止此类情况发生，但这些措施未能按预期保护代码仓库。我像攻击者一样，反复用不同变体测试 GitHub，并添加关键词“Additionally”，触发了模型的意外行为，使其重新组织输出内容而非拒绝请求。本质上，通过欺骗模型，我成功让 GitHub 的防护措施失效，未能阻止数据泄露。

漏洞概念验证

本着完全透明的原则，Noma Lab 的确认发现，包括我们的工作流复现过程和实时证据，可在此处查看：

工作流运行：https://github.com/sasinomalabs/poc/actions/runs/23909666039

问题：https://github.com/sasinomalabs/poc/issues/153

泄露的数据包括以下仓库中 README.md 的内容：

sasinomalabs/poc（公开仓库）

sasinomalabs/remote-ping（公开仓库，已确认无 README）

sasinomalabs/testlocal（私有仓库）

为何重要

GitLost 完美地说明了每个组织在使用智能体 AI 系统时面临的一个基本安全挑战。智能体的上下文窗口同时也是其攻击面。智能体读取的任何内容，无论是问题、拉取请求、评论还是文件，如果智能体将该内容视为指令输入，都可能被武器化。

传统安全模型通常假设信任边界由代码强制执行。在智能体系统中，信任边界部分由模型的行为强制执行，而模型天生遵循指令。提示词注入攻击对于智能体 AI 而言，已变得如同 SQL 注入对于 Web 应用程序一样：一种系统性的、跨类别的漏洞类型，需要同样系统性的策略和防御手段。

Noma 对构建者/AI 安全负责人的建议：

切勿将用户可控的内容视为 AI 智能体的可信指令输入

将权限范围限定在所需的最小限度。具有跨仓库访问权限的智能体是尤其高价值的目标

限制任何智能体公开发布的内容，特别是针对问题内容的回复

在将用户输入传递给模型之前，对其进行清理或与指令上下文隔离

负责任的披露

GitLost 已通过负责任的披露流程告知 GitHub。漏洞详情在此分享，已获其知情同意。

觉得这个有意思？订阅 Noma Labs，获取更多关于智能体 AI 漏洞的研究，或查看：GrafanaGhost、DockerDash、Context Crush、GeminiJack。正在寻找有效的智能体 AI 安全解决方案？联系我们，预约 Noma 全面解决方案的演示。

阅读时间：5 分钟

分类：

Noma Labs