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
GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos
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:
- Workflow run: https://github.com/sasinomalabs/poc/actions/runs/23909666039
- Issue: https://github.com/sasinomalabs/poc/issues/153
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 to arrange a demo of Noma’s comprehensive solution.
5 min read