文章总结： GitLost攻击技术利用GitHubAgenticWorkflow的间接提示注入漏洞，攻击者通过公开问题诱骗AI代理泄露私有仓库内容。该攻击无需凭证或访问权限，仅需代理拥有跨仓库读取权限。研究人员发现仅一个单词改动即可绕过GitHub防护。建议将代理令牌限定于单个仓库、限制公开输出并设置人工审核，以降低泄露风险。 综合评分： 85 文章分类： AI安全,漏洞分析,红队,安全工具,威胁情报

GitLost：诱骗 GitHub AI 代理泄露私有仓库

Swati Khandelwal Swati Khandelwal

代码卫士

2026年7月8日 15:58 北京

在小说阅读器读本章

去阅读

  聚焦源代码安全，网罗国内外最新资讯！

编译：代码卫士

Noma Security公司的研究人员表示，一个被称为 “GitLost” 的攻击技术，可诱骗 GitHub Agentic Workflow 泄露组织机构的私有仓库内容。

攻击者只需在公共仓库中打开一个看似正常的问题，无需窃取任何凭据，也无需任何访问权限即可发动攻击。如果该组织机构已授予代理在其所有仓库（包括私有仓库）中的读取权限，那么该问题就可以引导代理将私有内容拉取到公开评论中。

Noma将这种技术称为GitLost，它的目标是GitHub 在2月份推出的公开预览功能GitHub Agentic Workflows。与编写自动化脚本不同，用户只需在Markdown文件中用简单的英语向AI代理提供指令，该代理就会读取问题和拉取请求，运行工具，并自行回复。

该功能可由GitHub Copilot、Anthropic的Claude、Google Gemini或OpenAI Codex驱动。虽然工作流默认为只读，但组织机构可为工作流提供一个访问令牌，使其能够读取组织机构内的所有仓库（包括私有仓库），获得跨仓库的上下文。正是这种授权，成为GitLost加以利用的前提条件。

攻击原理

这种弱点即众所周知的间接提示注入。AI代理无法可靠地区分来自所有者的指令与它恰好读取到的内容中隐藏的指令之间的差别。因此，如果攻击者将这些指令写入一个问题中，代理很可能就会直接遵循这些指令。

在研究人员的概念验证中，恶意问题被伪装成销售副总裁在客户会议后提出的常规请求。它触发的工作流被设置为：当有问题被分配时即被唤醒，读取该问题，然后回复一条评论。同时，该工作流还被授予了对该组织其它仓库的读取权限。一旦某个常规自动化流程分配了该问题，代理就会拉取一个私有仓库的README文件，并将其粘贴到该问题的公开评论中。

GitHub为此设置了防护措施。GitHub 在官方文档中警告称“AI代理可能受到提示注入、恶意仓库内容或受损工具的操纵”，并且该产品内置了沙箱、默认只读令牌、输入清理，以及在代理发布内容之前对其输出进行扫描的威胁检测步骤。研究人员报告称，在测试中，仅一个单词的改动就足以绕过防护。在恶意指令前加上“Additionally”，会让模型将其视为后续任务而非需要拒绝的内容，于是防护机制便予以放行。

不同之处

GitLost的与众不同之处在于攻击者所能控制的对象。研究人员表示：“早期的提示注入示例主要侧重于操纵代理说什么，而GitLost则是操纵代理如何利用其权限行事。”这里的代理不是一个聊天窗口，而是一个持有凭证的实体，位于组织内与CI/CD相邻的基础设施中，拥有跨越攻击者无法看到的仓库的读取权限。它不接触任何服务器，不需要窃取凭证，也不需要任何私有内容的写入权限。攻击者只需打开一个公开问题即可。这种设定符合开发者Simon Willison所称的“致命三重奏”，Levi也使用了同样的术语：一个能够接触私有数据的代理，接收来自外部不受信任的内容，并且有办法将数据发送出去。三者结合，就构成了泄露路径。

该漏洞并非通过打补丁就能关闭的漏洞；正如Levi所言，这是给AI代理赋予长期凭据同时又让它们读取攻击者可触及文本所带来的结构性后果。

类似攻击频发

GitLost是同类攻击中的最新一起。比如，Claude Code GitHub Action中的一个缺陷导致一个恶意问题就能推动代理泄露机密并夺取仓库的写入权限。Orca Security公司的RoguePilot利用GitHub问题中的隐藏提示，让Copilot泄露了仓库的特权令牌。涉及GitHub代理的问题至少可以追溯到2025年5月，当时Invariant Labs演示了一个公开问题如何推动连接到GitHub MCP服务器的代理读取私有仓库并通过拉取请求将其泄露；研究人员称这属于架构性问题，服务器端补丁无法解决。一项名为“评论与控制”的跨厂商研究又成功诱使Claude Code、Gemini CLI和GitHub Copilot代理通过问题和拉取请求文本泄露了自己的API密钥，并绕过GitHub后来添加的运行时防御措施。

应对措施

受GitLost漏洞影响的范围仅限于已启用预览版，并将代理配置为读取不受信任的公开输入，同时持有私有仓库读取权限且能够在公开渠道发帖的组织机构。

攻击者能够获取的权限取决于代理令牌的可见范围，从专有源代码到内部密钥、设计文档或CI/CD机密都有可能。正如Levi所言，范围最为关键：将代理令牌限定在它所处理的单个仓库内，“远比为了方便而授予整个组织的广泛读取权限要安全得多”。

在实际操作中，这种跨仓库访问权限来自组织机构设置的个人访问令牌，因此应将令牌的作用范围限定在工作流所处理的仓库，而非整个组织。写入操作只应通过声明为安全的输出进行，所以要限制面向公众的工作流能够发布什么内容，因为它产生的评论就是泄露通道。同时，限制代理会对哪些作者的内容采取行动，并在其输出之后设置人工审核环节。

虽然GitHub的威胁检测步骤会在代理发布前扫描输出，但本案例仅用一个单词就绕过的事实提醒我们，过滤器只能作为最后一道防线，而非边界。与其他厂商一样，GitHub为此类攻击设置了防护措施，但通过一个单词的改动就绕过了这些措施。研究人员和厂商都一再将这种结果归因于“架构性限制”，而Levi的观点解释了为何这个标签一直适用：在自然语言中，数据和指令之间并没有像SQL那样的清晰界限，因此解决方案更依赖架构层面的设计，而非单纯过滤掉注入内容，即依赖隔离、受限凭据和分阶段审核。在这种边界建立之前，任何能读取私有数据、接收不受信任输入并且能在公开渠道发帖的代理，距离因一个精心措辞的问题而导致泄露，只有一步之遥。

开源卫士试用地址：https://oss.qianxin.com/#/login

代码卫士试用地址：https://sast.qianxin.com/#/login

推荐阅读

GitHub 推出 npm 安全变更，对抗供应链攻击

自动化供应链攻击6小时内攻陷5561个 GitHub 仓库

GitHub Copilot 严重漏洞可导致私有仓库源代码被盗

Slack 的GitHub 私有仓库被盗

原文链接

https://thehackernews.com/2026/07/public-github-issue-could-trick-github.html

题图：Pixabay License

本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。

奇安信代码卫士 (codesafe)

国内首个专注于软件开发安全的产品线。

    觉得不错，就点个 “在看” 或 “赞” 吧~

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：代码卫士 Swati Khandelwal Swati Khandelwal《GitLost：诱骗 GitHub AI 代理泄露私有仓库》