GitLost:Noma Labs 发现 GitHub AI 代理提示词注入漏洞
GitLost:我们诱使 GitHub 的 AI 代理泄露了私有仓库
Noma Labs 在 GitHub Agentic Workflows 中发现严重提示词注入漏洞 GitLost。未认证攻击者仅需在属于同一组织的公共仓库中创建一个嵌有恶意指令的 Issue,即可诱使基于 Claude 或 GitHub Copilot 的 AI 代理读取并公开该组织内私有仓库的内容。攻击无需编码技能或凭证,根源在于代理将用户可控内容视为可信指令,且 GitHub 的防护措施因 "Additionally" 关键词被绕过。Noma Labs 已公开 PoC 并建议限制跨仓库权限、隔离用户输入。
GitLost 是第一个有完整复现的 GitHub AI 代理泄露私有仓库漏洞,展示了 AI 代理的上下文窗口即攻击面,做 AI 应用或 CI/CD 的人都该看一下。
TL;DR:Noma Labs 在 GitHub 新推出的 Agentic Workflows 中发现了一个严重的提示词注入漏洞,未经身份验证的攻击者只需在与私有仓库同属一个组织的公开仓库中发布一个精心构造的 GitHub Issue,就能悄无声息地从私有仓库中窃取数据。Noma Labs 将该漏洞命名为 GitLost。
引言
GitHub 最近推出了 GitHub Agentic Workflows,将 GitHub Actions(GitHub 用于响应仓库事件运行任务的自动化系统)与由 Claude 或 GitHub Copilot 驱动的 AI 智能体配对。GitHub Agentic Workflows 允许团队用纯 Markdown 编写 GitHub 工作流,GitHub 智能体会自行读取 issue、调用工具并作出响应。作为一名有安全开发背景的漏洞研究员,这次发布后我脑海中浮现的第一个问题既根本又直接:当 GitHub 智能体读到了它本不该信任的内容时,会发生什么?
答案是教科书式的间接提示词注入攻击,这类攻击会悄无声息地把私有数据发送给互联网上的任何人。提示词注入是一类攻击,攻击者将恶意指令隐藏在 AI 智能体所读取的内容中。这些内容会使智能体遵循那些隐藏指令,而非其运营者原本意图的指令。
什么是 GitHub Agentic Workflows?
GitHub Agentic Workflows 让团队能够使用自然语言自动化其与代码仓库的交互。工作流存放在 Markdown(.md)文件中,会被编译为 YAML(一种常见的配置文件格式)格式的 Actions 文件,扩展名为 .yml,并在一个具有可配置权限的 AI 智能体的协助下运行。该 GitHub 智能体可以读取 issue、调用工具,并访问组织内的其他仓库。
GitLost 漏洞概述
GitLost 漏洞的根本原因,在如今的智能体 AI 系统中已经是一个耳熟能详的问题:提示词注入。在大多数智能体提示词注入攻击中,智能体会把错误的内容当作可信的指令来源,从而让自己被误导或滥用。当系统未能在系统级指令与不可信的用户数据之间维持严格的信任边界时,这种情况就会发生。在这个具体案例中,任何恶意行为者都可以创建一个 GitHub Issue,并在 issue 正文中用浅显易懂的英文隐藏命令,而 GitHub 的智能体会照此执行。
Noma Labs 发现的那个存在漏洞的 GitHub Agentic Workflow 被配置为:
- 在 GitHub 中通过 issues.assigned 事件触发该工作流
- 读取 issue 的 Title 和 Body
- 使用 add-comment 工具发布一条评论作为回应
- 以对组织内其他仓库(公开和私有)的读取权限运行
要利用这个漏洞,攻击者不需要任何编程技能、访问权限或凭据。只需在一个使用 GitHub Agentic Workflow 配置的组织所属的公开仓库中提交一个 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、pull request、评论还是文件,只要智能体将这些内容当作指令性输入来对待,就可能被武器化。
传统安全模型通常假设信任边界由代码来强制执行。在智能体系统中,信任边界部分由模型的行为来强制执行,而模型天生就是遵循指令的。提示词注入攻击之于智能体 AI,正如 SQL 注入之于 Web 应用:一个系统性的、覆盖整个类别的漏洞类型,需要同样系统性的策略和防御。
Noma 给构建者/AI 安全负责人的建议:
- 绝不要将用户可控的内容当作 AI 智能体的可信指令输入
- 将权限限定在所需的最小范围。拥有跨仓库访问权限的智能体尤其是高价值目标
- 限制任何智能体可以公开发布的内容,尤其是针对 issue 内容的回复
- 在将用户输入传递给模型之前,对其进行净化或将其与指令上下文隔离
负责任披露
GitLost 已按照负责任披露流程向 GitHub 报告。漏洞详情是在他们知情的情况下在此分享的。
觉得这个有意思?订阅 Noma Labs 获取更多智能体 AI 漏洞研究,或查看:GrafanaGhost、DockerDash、Context Crush、GeminiJack。正在寻找有效的智能体 AI 安全解决方案?联系我们安排演示,了解 Noma 的全面解决方案。
来源:Hacker News 热门(buzzing.cc 中文翻译) · noma.security