# 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 驱动的人工智能智能体相结合。GitHub 智能体工作流允许团队用纯 Markdown 编写工作流，而 GitHub 智能体会自行读取 Issue、调用工具并做出响应。作为一名拥有安全开发背景的漏洞研究员，这次发布后我脑海中首先浮现的问题既基础又直白：当 GitHub 智能体读取了它不应信任的内容时，会发生什么？ 答案是一个典型的间接提示词注入攻击——这种攻击能悄无声息地将私有数据发送给互联网上的任何人。提示词注入是一类攻击方式，攻击者将恶意指令隐藏在 AI 智能体所读取的内容中，导致智能体按照这些隐藏指令行事，而非遵循操作者的本意。 什么是 GitHub 智能体工作流？ GitHub 智能体工作流让团队能够使用自然语言自动化与代码仓库的交互。工作流以 Markdown（.md）文件的形式存在，会被编译成 YAML（一种常见的配置文件格式）以及扩展名为 .yml 的 Actions 文件，并在一个具有可配置权限的人工智能智能体的协助下运行。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 Issue：https://github.com/sasinomalabs/poc/issues/153 泄露的数据包括来自以下仓库的 README.md 内容： sasinomalabs/poc（公开仓库） sasinomalabs/remote-ping（公开仓库，已确认无 README） sasinomalabs/testlocal（私有仓库） 为什么这很重要 GitLost 完美展示了每个组织在使用 AI 智能体系统时面临的基本安全挑战之一。智能体的上下文窗口同时也是它的攻击面。智能体读取的任何内容——无论是 Issue、拉取请求、评论还是文件——如果智能体将该内容视为指令输入，都可能被武器化。 传统安全模型通常假设信任边界由代码来强制执行。而在智能体系统中，信任边界部分由模型的行为来强制执行，而模型天生就遵循指令。提示词注入攻击对 AI 智能体而言，已变得像 SQL 注入对 Web 应用一样：一种系统性的、跨类别的漏洞类型，需要同样系统性的策略和防御手段。 Noma 对构建者/AI 安全负责人的建议： 切勿将用户控制的内容视为 AI 智能体的可信指令输入 将权限范围限制到所需的最小程度。拥有跨仓库访问权限的智能体是尤其高价值的目标 限制任何智能体公开发布的内容，尤其是在响应 Issue 内容时 在将用户输入传递给模型之前，对用户输入进行清理或将其与指令上下文隔离 负责任的披露 GitLost 已通过负责任的披露方式报告给 GitHub。漏洞详情已在其知情的情况下在此共享。 觉得这很有趣？订阅 Noma Labs 获取更多智能体 AI 漏洞研究，或者查看：GrafanaGhost、DockerDash、Context Crush、GeminiJack。正在寻找有效的智能体 AI 安全解决方案？联系我们安排 Noma 全面解决方案的演示。 5 分钟阅读 分类： Noma Labs 目录 发现更多 问得好 – Claude 标签与智能体身份：IAM 会有什么变化？ 2026 年 6 月 28 日 Noma 与 Kong 合作，保障智能体 AI 时代的安全 2026 年 6 月 24 日 问得好 – 你的智能体所遵循的指令是谁写的？ 2026 年 6 月 24 日