GitLost：一个公开 Issue，为什么能骗 GitHub AI Agent 泄露私有仓库？

原创

做安全的小明同学
做安全的小明同学

大山子雪人

2026年7月9日 11:42
北京

在小说阅读器读本章

去阅读

GitLost：一个公开 Issue，为什么能骗 GitHub AI Agent 泄露私有仓库？

AI Agent 进入研发流程后，真正危险的不是“它会不会写错代码”，而是：
它读了谁的话、拿着谁的权限、最后把结果发到了哪里。

近日，Noma Security 发布了一篇名为 GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos 的研究文章，披露了一个针对 GitHub Agentic Workflows 的提示词注入问题：攻击者无需账号权限，只要在目标组织的公开仓库里提交一个看似正常的 Issue，就有机会诱导 AI Agent 读取同组织私有仓库内容，并把结果回复到公开 Issue 评论区。Noma 将这一问题命名为 GitLost。(noma.security)

这件事最值得关注的地方不在于“提示词注入”这个词本身，而在于它把 AI Agent 的三个高危条件凑到了一起：

一句话概括：

攻击者不需要直接访问私有仓库，只需要让“有权限的 Agent”替自己去读。

1. GitHub Agentic Workflows 是什么？

GitHub Agentic Workflows 是 GitHub 推出的 AI 自动化工作流能力，目标是让团队用 Markdown 描述自动化任务，而不是直接写复杂 YAML。GitHub 官方介绍中提到，这类工作流可以用于 Issue 分流、PR Review、CI 失败分析、仓库维护等任务，并运行在 GitHub Actions 体系内。(github.blog)

官方设计里也强调了安全机制，例如默认只读权限、沙箱执行、安全输出、威胁检测等。GitHub Agentic Workflows 文档还明确提到，AI Agent 可能受到 Prompt Injection、恶意仓库内容或被攻陷工具影响，因此需要分层防护。(github.github.com)

但 GitLost 说明了一个现实问题：

只读并不等于安全。
如果 Agent 能读私有数据，又能把结果写到公开位置，泄露仍然会发生。

2. GitLost 的攻击链路

Noma 的研究中，存在问题的工作流大致具备以下特征：

1. 1. 工作流由 issues.assigned 等 Issue 相关事件触发；
2. 2. Agent 会读取 Issue 的标题和正文；
3. 3. Agent 可以调用工具向 Issue 添加评论；
4. 4. Agent 被配置了对组织内其他仓库的读取权限，包括私有仓库。(noma.security)

攻击者只需要在公开仓库创建一个看似正常的 Issue，在正文里埋入指令，让 Agent 在处理任务时“顺手”读取其他仓库内容。随后，Agent 会把读取到的内容作为公开评论回复出来。Noma 的 PoC 中，Agent 最终读取并公开回复了公开仓库和私有仓库中的 README 内容。(noma.security)

这个过程的关键不是漏洞利用代码，而是信任边界混乱：

公开 Issue 内容
   ↓
被 Agent 当作任务指令读取
   ↓
Agent 使用自身权限访问私有仓库
   ↓
Agent 将结果写入公开评论区

从传统安全视角看，攻击者没有 Token、没有私有仓库权限、没有登录组织内部系统。

但从 Agent 视角看，攻击者成功操控了一个“有权限的执行者”。

3. 这不是“模型太笨”，而是系统边界没设计好

很多人看到这类问题，第一反应可能是：“那就让模型识别恶意提示词不就行了？”

问题在于，Agent 处理的是自然语言，而自然语言天然很难像代码一样严格区分“数据”和“指令”。

Noma 在原文中提到，GitHub 已有防护机制，但研究者通过反复变体测试，使用一个非常普通的连接词触发了模型的非预期行为，使其绕过原本应该拒绝的场景。(noma.security)

这说明单纯依赖模型拒答或内容过滤并不可靠。它更适合作为兜底，而不是安全边界。

真正的问题是：

4. 为什么这个问题值得重视？

GitLost 的本质是 Indirect Prompt Injection，也就是“间接提示词注入”。

攻击者并不直接和 AI 对话，而是把恶意指令藏在 AI 未来会读取的内容里，比如：

• • GitHub Issue；
• • PR 描述；
• • Issue 评论；
• • README；
• • 文档；
• • 邮件；
• • 工单；
• • Jira / 飞书 / Slack 消息。

当 Agent 自动读取这些内容时，就可能把其中的恶意文本当成任务指令执行。

OWASP LLM Top 10 也将 Prompt Injection 列为 LLM 应用的重要风险之一，认为攻击者可以通过输入改变模型行为、绕过安全措施或触发非预期操作。(genai.owasp.org)

对于研发场景来说，这类问题尤其危险，因为 AI Agent 往往天然靠近：

• • 源代码；
• • CI/CD；
• • GitHub Token；
• • 云凭据；
• • 内部文档；
• • 私有 Issue；
• • PR Review 流程；
• • 自动化发布链路。

也就是说，AI Agent 一旦被注入，它不只是“回答错了”，而可能成为供应链攻击中的执行节点。

5. 相似案例：GitLost 并不是孤例

5.1 GitHub MCP 私有仓库泄露问题

2025 年，Invariant Labs 披露过一个与 GitHub MCP 集成相关的问题：攻击者可以通过公开仓库中的恶意 Issue 劫持用户的 Agent，并诱导它访问私有仓库，再将敏感数据泄露出去。该研究同样强调，这不是简单的代码 Bug，而是 Agent 拥有过宽权限后，无法可靠区分可信指令与不可信内容导致的架构问题。(invariantlabs.ai)

这个案例和 GitLost 的相似点非常明显：

区别在于，GitLost 更贴近 GitHub 官方 Agentic Workflows 这种平台化自动化场景。

5.2 RoguePilot：GitHub Issue 到 Copilot / Codespaces 劫持

Orca Security 在 2026 年披露的 RoguePilot 研究中，也展示了类似的被动提示词注入风险：攻击者可以把隐藏指令放进 GitHub Issue，当用户从该 Issue 启动 Codespaces 并使用 Copilot 时，Agent 可能被操控，进而泄露高权限 GITHUB_TOKEN，最终导致仓库接管风险。(orca.security)

这个案例说明，GitHub Issue 不再只是“协作文本”，它已经变成 Agent 的输入面。

过去我们审计 Issue，主要关心 XSS、链接钓鱼、社工欺骗。

现在还要关心：

这段文字会不会被 Agent 当成命令执行？

5.3 Comment and Control：评论区变成 Agent 的 C2 通道

Aonan Guan 等研究者在 Comment and Control 中总结了另一类模式：GitHub 的 PR 标题、Issue 正文、Issue 评论都可能变成 Prompt Injection 入口，进而劫持运行在 GitHub Actions 中的 AI Agent，并窃取 API Key 或 Token。该研究涉及 Claude Code Security Review、Gemini CLI Action、GitHub Copilot Agent 等多个 Agent。(oddguan.com)

这个名字很形象：

Command & Control  →  Comment & Control

也就是说，攻击者不再需要传统 C2 基础设施。

GitHub 评论区本身，就可能成为控制 Agent 的入口。

5.4 学术研究：Agentic Workflow Injection 正在规模化出现

2026 年 5 月的一篇论文提出了 Agentic Workflow Injection（AWI） 概念，专门描述 GitHub Actions 中 AI Agent 工作流的注入问题。研究者将其分为两类：Prompt-to-Agent 和 Prompt-to-Script，即不可信 GitHub 事件内容进入 Agent Prompt，或通过模型输出继续影响后续脚本逻辑。(arxiv.org)

该研究对 13,392 个真实 Agentic Workflow 进行分析，报告了 519 个潜在 AWI 漏洞，其中 496 个在其威胁模型下被确认可利用，精度为 95.6%。(arxiv.org)

另一篇 GitInject 研究则指出，AI Agent 被嵌入 CI/CD 后，会同时面对不可信输入和较高仓库权限；研究覆盖四类 AI Provider 的工作流配置，并发现默认配置下所有被测 Provider 至少容易受到一种攻击类别影响。(arxiv.org)

这些研究共同指向一个结论：

AI Agent 安全问题正在从单点 Prompt Hack，变成 CI/CD 与软件供应链里的系统性攻击面。

6. GitLost 给我们的核心启示

GitLost 不是“某个模型说错话”，而是一个典型的 Agent 安全三角问题：

不可信输入 + 敏感权限 + 可外发输出 = 数据泄露

只要这三个条件同时存在，风险就会被放大。

对于企业来说，评估 AI Agent 风险时，不应该只问：

• • 用的是什么模型？
• • Prompt 写得好不好？
• • 有没有安全提示词？

更应该问：

7. 结语：Agent 安全的关键不是“让模型更听话”

GitLost 最大的警示是：

AI Agent 越能干，越不能用“聊天机器人”的安全模型来管理它。

过去，一个普通用户提交的 GitHub Issue 只是文本。

现在，它可能是 Agent 的输入、上下文、任务描述，甚至是间接命令。

过去，GitHub Token 只是给脚本用。

现在，它可能被 Agent 在复杂上下文中调用。

过去，公开评论只是协作回复。

现在，它可能变成数据外传通道。

所以，Agent 安全的核心不是写一句“不要泄露敏感信息”，而是重新设计：

身份
权限
输入边界
工具边界
输出边界
审计链路
人工审批

真正安全的 Agent 系统，应该默认假设：

任何它读到的外部内容，都可能是攻击者写给它的命令。

而系统要做的，不是期待模型永远分得清，而是即使模型被诱导，也没有权限把事情做坏。

参考资料

1. 1. Noma Security：GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos。(noma.security)
2. 2. GitHub：Agentic Workflows technical preview / 官方文档。(github.blog)
3. 3. GitHub Agentic Workflows：Threat Detection 文档。(github.github.com)
4. 4. The Hacker News：Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data。(thehackernews.com)
5. 5. Invariant Labs：GitHub MCP Exploited: Accessing private repositories via prompt injection。(invariantlabs.ai)
6. 6. Orca Security：RoguePilot: Exploiting GitHub Copilot for a Repository Takeover。(orca.security)
7. 7. Aonan Guan：Comment and Control: Prompt Injection to Credential Theft in Claude Code, Gemini CLI, and GitHub Copilot Agent。(oddguan.com)
8. 8. arXiv：Demystifying and Detecting Agentic Workflow Injection Vulnerabilities in GitHub Actions。(arxiv.org)
9. 9. arXiv：GitInject: Real-World Prompt Injection Attacks in AI-Powered CI/CD Pipelines。(arxiv.org)
10. 10. OWASP：LLM01 Prompt Injection。(genai.owasp.org)