🔶 GitLost:我们诱骗 GitHub 的 AI Agent 泄露私有仓库
英文标题:🔶 GitLost: We Tricked GitHub's AI Agent into Leaking Private Repos
Noma Labs 在 GitHub 的 Agentic Workflows 中发现名为 GitLost 的严重提示注入漏洞,未认证攻击者只需在公开仓库提交精心设计的 Issue,即可让 AI Agent 读取并公开泄露同一组织内的私有仓库数据。漏洞根因在于 Agent 将不可信的用户内容当作指令执行,且攻击者通过“Additionally”等措辞绕过了 GitHub 的防护。这一发现表明,提示注入正成为 Agentic AI 系统类似 SQL 注入的系统性缺陷,凸显了在 AI 工作流中建立严格信任边界的紧迫性。
1.1 KB
523 B
1.5 KB
1.6 KB
1.5 KB
400 B
170 B
184.3 KB
541.1 KB
53.5 MB
107.6 KB
141.7 KB
4.1 MB
513.8 KB
2.7 MB
中文
简短摘要:Noma Labs 在 GitHub 新推出的 Agentic Workflows 中发现了一个严重的提示注入漏洞,未认证攻击者可通过在属于同一组织的公开仓库中提交特制的 GitHub Issue,悄无声息地窃取私有仓库的数据。Noma Labs 将此漏洞命名为 GitLost。
引言
GitHub 最近推出了 GitHub Agentic Workflows,将 GitHub Actions(GitHub 响应仓库事件运行任务的自动化系统)与基于 Claude 或 GitHub Copilot 的 AI Agent 相结合。GitHub Agentic Workflows 允许团队用纯 Markdown 编写工作流,并由 GitHub Agent 读取 Issue、调用工具并自行回复。
作为一名具有安全开发背景的漏洞研究员,此次发布后我首先想到的一个问题是基础而直接的:当 GitHub Agent 读到了本不该信任的内容时,会发生什么?
答案是一种典型的间接提示注入攻击,一种悄悄将私有数据发送给互联网上任何人的攻击。提示注入是一类攻击,攻击者将恶意指令隐藏在 AI Agent 阅读的内容中,导致 Agent 遵循这些隐藏指令,而非操作者原本的意图。
什么是 GitHub Agentic Workflows?
GitHub Agentic Workflows 允许团队使用自然语言自动化与代码仓库的交互。工作流存在于 Markdown (.md) 文件中,被编译成 YAML(一种常见的配置文件格式)即 .yml 扩展名的 Actions 文件,并借助拥有可配置权限的 AI Agent 运行。GitHub Agent 可以读取 Issue、调用工具并访问组织内的其他仓库。
GitLost 漏洞概览
GitLost 漏洞的根本原因在 Agentic AI 系统中已不陌生:提示注入。在大多数 Agentic 提示注入攻击中,Agent 会将不应信任的内容误认为是可信的指令来源,从而被误导或滥用。当系统无法在系统级指令和不可信用户数据之间维持严格的信任边界时,就会发生这种情况。在此具体案例中,任何恶意行为者都可以创建一个 GitHub Issue,并在 Issue 正文中用自然语言隐藏命令,GitHub Agent 将照做不误。
Noma Labs 发现的易受攻击的 GitHub Agentic Workflow 配置如下:
- 由 GitHub 中的 issues.assigned 事件触发工作流
- 读取 Issue 的标题和正文
- 使用 add-comment 工具回复评论
- 以读取权限访问组织中的其他仓库(公开和私有)
要利用此漏洞,攻击者无需编码技能、访问权限或凭据,只需在某个使用了 GitHub Agentic Workflow 设置的组织所拥有的公开仓库中创建一个 Issue 并等待即可。

攻击流程
下面来看看 Noma Labs 漏洞研究员成功实施的准确攻击流程:
首先,他们精心构造了一个看似完全无害的 GitHub Issue,内容为一位销售副总裁与客户会面后提出的合理请求,如下图所示:

在此特定示例中,工作流操作在 Issue 被分配时触发,但我们的测试证实,它对其他 GitHub 工作流操作同样有效。
接着,在 GitHub 自动化分配该 Issue 后,事件触发的工作流使 Agent 从 poc(公开)和 testlocal(私有)仓库中获取 README.md 的内容。
最后,GitHub Agent 将其作为公开评论发布在该公开仓库的 Issue 上,任何人都可以访问和阅读。
“追加”利用
GitHub 已设置了限制性防护措施来专门防范这种情况,但它们未能按预期保护仓库。我们像攻击者一样不断用各种变体测试 GitHub,并添加了关键词 “Additionally”,这引发了模型的非预期行为,使其重新调整输出而不是拒绝输出。本质上,通过欺骗模型,我得以确保 GitHub 的防护措施未按预期生效,未能阻止数据泄露。
漏洞概念验证
为完全透明,Noma Labs 确认的调查结果,包括我们的工作流重现和实时证据,可在此处找到:
泄露的数据包括以下仓库的 README.md 内容:
- sasinomalabs/poc(公开仓库)
- sasinomalabs/remote-ping(公开仓库,确认无 README)
- sasinomalabs/testlocal(私有仓库)
为何重要
GitLost 完美地展示了每个组织在引入 Agentic AI 系统时所面临的基本安全挑战之一。Agent 的上下文窗口同时也是它的攻击面。Agent 读取的任何内容,无论是 Issue、Pull Request、评论还是文件,一旦被 Agent 视为指令输入,都可能被武器化。
传统安全模型通常假设信任边界由代码强制执行。而在 Agentic 系统中,信任边界部分由模型的行为来决定,而模型天生就是遵循指令的。提示注入攻击之于 Agentic AI,正如 SQL 注入之于 Web 应用:一个系统性的、涵盖整个漏洞类别的缺陷,需要同样系统性的策略和防御措施。
Noma 对构建者/ AI 安全负责人的建议:
- 永远不要将用户控制的内容作为 AI Agent 的可信指令输入
- 将权限范围限制在最小必要程度。具有跨仓库访问权限的 Agent 是价值极高的目标
- 限制 Agent 公开发布任何内容,尤其是在响应 Issue 内容时
- 在将用户输入传递给模型之前,将其与指令上下文进行净化或隔离
负责任的披露
GitLost 已负责任地向 GitHub 进行了披露。漏洞细节在此处共享已获其知悉。
English / 原文
TL;DR : Noma Labs discovered a critical prompt injection vulnerability within GitHub’s new Agentic Workflows, allowing an unauthenticated attacker to silently pull data from private repositories by posting a crafted GitHub Issue in a public repository belonging to the same organization as the private repositories. Noma Labs named the vulnerability GitLost.
Introduction
GitHub recently launched GitHub Agentic Workflows, pairing GitHub Actions (GitHub’s automation system for running tasks in response to repository events) with an AI agent backed by Claude or GitHub Copilot. GitHub Agentic Workflows allow teams to write their GitHub workflows in plain Markdown, and the GitHub agent reads issues, calls tools, and responds on its own.
As a vulnerability researcher with a security development background, one of the first questions that came to mind after this launch was fundamental and straightforward: What will happen when the GitHub agent reads something it should not trust?
The answer is a textbook indirect prompt-injection attack, the kind of attack that quietly sends private data to anyone on the internet. Prompt injection is a class of attack in which an adversary hides malicious instructions inside the content read by an AI agent. That content causes the agent to follow those hidden instructions instead of the ones its operator intended.
What are GitHub Agentic Workflows?
GitHub Agentic Workflows let teams automate their interactions with code repositories using natural language. Workflows live in Markdown (.md) files, are compiled into YAML (a common configuration file format), Actions files with the .yml extension, and run with the help of an AI agent with configurable permissions. The GitHub agent can read issues, call tools, and access other repositories within an organization.
GitLost Vulnerability Overview
The root cause of the GitLost vulnerability is, by now, a familiar one in agentic AI systems: prompt injection. In most agentic prompt injection attacks, the agent treats the wrong content as a trusted source of instructions and allows itself to be misdirected or misused. This happens when the system fails to maintain a strict trust boundary between system-level directives and untrusted user data. In this specific case, any malicious actor can create a GitHub Issue and, in the issue body, hide commands in plain English that GitHub’s agent will follow.
The vulnerable Github Agentic Workflow Noma Labs discovered was configured to:
- Trigger the workflow on issues.assigned events in GitHub
- Read the issue Title and Body
- Post a comment in response using the add-comment tool
- Run with read access to other repositories (public and private) in the organization
To exploit this vulnerability, the attacker needed no coding skills, access, or credentials. All that was needed was to open an issue in a public repository belonging to an organization that uses GitHub’s Agentic Workflow setup and wait.

The Attack Flow
Let’s take a look at the exact attack flow that Noma Labs vulnerability researchers succeeded with:
First, they crafted a GitHub issue that looked completely innocent, consisting of a plausible-looking request from a VP Sales after meeting with a customer, as shown below:

In this specific example, the workflow action was triggered when the issue was assigned , but our testing confirmed it works the same way for other GitHub workflow actions.
Then, after a GitHub automation assigned the issue, an event-triggered workflow caused the agent to fetch the contents of README.md from both the poc (public) and testlocal (private) repositories.
Finally, the GitHub agent then posted them as a public comment on the issue in the public repository, which anyone could access and read.
The “Additional” Exploit
GitHub had restrictive guardrails in place to prevent exactly this scenario, but they failed to protect the repositories as intended. Testing GitHub repeatedly with variations, as an attacker would, and adding the keyword “Additionally” triggered unintended behavior in the model, causing it to reframe its output rather than refuse it. Essentially, by tricking the model, I was able to ensure that GitHub’s guardrails did not work as intended and didn’t prevent the data leak.
Vulnerability Proof of Concept
With the goal of full transparency, Noma Lab’s confirmed findings, including our workflow reproductions and live evidence, can be found here:
The leaked data included the contents of README.md from:
- sasinomalabs/poc (public repo)
- sasinomalabs/remote-ping (public repo, no README confirmed)
- sasinomalabs/testlocal (private repo)
Why it Matters
GitLost perfectly illustrates one of the fundamental security challenges every organization faces with agentic AI systems. The agent’s context window is also its attack surface. Any content the agent reads, whether issues, pull requests, comments, or files, can be weaponized if the agent treats that content as instructional input.
Traditional security models typically assume that trust boundaries are enforced by code. In agentic systems, trust boundaries are partly enforced by the model’s behavior, and models are inherently instruction-following. Prompt injection attacks have become, to agentic AI, what SQL injections were to web applications: a systematic, category-wide vulnerability class that requires the same systematic strategies and defenses.
Noma Recommendations for Builders/AI Security Officers:
- Never treat user-controlled content as trusted instruction input for an AI agent
- Scope permissions to the minimum required. Agents with cross-repository access are especially high-value targets
- Restrict what any agent can post publicly, especially in response to issue content
- Sanitize or isolate user input from the instruction context before passing it to the model
Responsible Disclosure
GitLost was responsibly disclosed to GitHub. Vulnerability details are shared here with their knowledge.
Found this interesting? Subscribe for more agentic AI vulnerability research by Noma Labs, or check out: GrafanaGhost, DockerDash, Context Crush, GeminiJack. Looking for an effective Agentic AI Security Solution? Contact us toarrange a demo of Noma’s comprehensive solution.