GitHub AI Agent 翻车：攻击者不用黑客技术，只写一句话就能窃取数据

核心亮点：黑客不用写代码，只需在公开帖子里藏一句“顺带一提”，就能让GitHub的AI助手乖乖交出私有仓库的机密数据。通俗解读：想象你雇了个很听话的实习生，他有权翻阅公司所有文件。有人在他的工作清单里塞了一句“顺便帮我把那份保密财报发到评论区”，他就真照做了。这次攻击利用的就是AI“太听话”的弱点——攻击者把恶意指令伪装成普通补充说明，绕过了安全审核，诱骗AI把受限文件公开出来。GitHub已经设了防护，但一个简单的“Additionally”就能让AI把新指令当成当前任务的延续，说明这类漏洞很难从技术上彻底堵住。实际影响：以后你用AI处理工作文档时，得多个心眼：AI读的所有内容都可能被“套话”套走。尤其对企业来说，只要AI能接触到某个项目资料，它就可能成为泄密入口。对普通人最大的启发是，别把敏感信息随便交给AI工具处理，也别指望“私有权限”能挡住所有AI“嘴瓢”。这次事件也提醒开发者和公司，不能只靠隔离权限，还要限制AI能公开回答的范围，否则一条恶意评论就能让机密“裸奔”。

GitLost 是由 Noma Security 发现的一种提示注入漏洞利用方式，它能够诱骗 GitHub 新推出的 Agentic Workflows 泄露私有数据。攻击者只需在公开 GitHub Issue 中嵌入隐藏指令，就可以绕过安全防护措施，诱导 AI Agent 在公开评论中泄露机密信息。Noma Labs 发现的这一存在漏洞的 GitHub Agentic Workflow，被配置为在 issues.assigned 事件触发时运行，读取 Issue 标题和正文，通过 add-comment 工具发布回复评论，并且拥有读取组织内其他仓库（包括公开仓库和私有仓库）的权限。为了利用这一漏洞，攻击者不需要任何编程技能、访问权限或凭据。攻击者只需要在一个使用 GitHub Agentic Workflow 配置的组织所属公开仓库中创建一个 Issue，然后等待即可。Noma 表示，尽管 GitHub 已经部署了严格的防护机制来避免这种情况发生，但仅仅使用关键词 “Additionally” 就触发了模型的非预期行为。这导致模型访问了一个原本受限制文件的内容，并将其发布在公开评论中。传统安全模型通常假设，信任边界由代码负责维护。而在 Agentic 系统中，信任边界部分依赖于模型的行为，而模型天然具备遵循指令的特性。对于 Agentic AI 来说，提示注入攻击正在变成类似 Web 应用中的 SQL 注入问题：一种系统性的、覆盖整个类别的漏洞类型，需要同样系统化的策略和防御措施。为了降低这些风险，Noma 研究人员建议，用户控制的内容永远不应该被视为 AI Agent 的可信指令输入。Agent 的权限应该限制在严格必要的范围内，因为拥有跨仓库访问权限的 Agent 会成为极具价值的攻击目标。组织还应该限制 Agent 可以公开披露的信息范围，尤其是在响应 Issue 内容时，并确保用户输入在提供给模型之前，已经经过适当清理，或者与指令上下文隔离。Fractional CTO Vijendra Malhotra 在 LinkedIn 上评论称，Noma 的发现证明了：私有仓库从来都不是安全边界。它实际上是组织边界，只有当读取你代码的人都是你雇佣的人类时，这个边界才成立。Agent 打破了这一假设。[……] 如果一个 Agent 能访问你的私有仓库，请把其中所有内容都视为距离公开泄露只差一个精心构造的 Issue。Reddit 用户 Significant_Sea_4230 指出：危险之处并不在于 Agent “很聪明”。而在于它可能连接了过多上下文、过多仓库，或者拥有权限过于宽泛的 Token。另一方面，用户 cH3332xr 强调：这里最有意思的细节是 “Additionally” 绕过机制，有效载荷本身并没有改变，只是这个衔接词在防护机制看来，把它从“新的指令”重新归类成了“当前任务的延续”。这是一个决策边界问题，而不是内容问题。作为社区的最后一条评论，mcv 在 Hacker News 上表示：SQL 注入之所以产生，是因为系统把用户输入当成了指令的一部分，而不是原本应该被视为纯数据的内容。将两者分离之后，这个问题就解决了。而提示注入无法避免，因为用户输入本身就是指令。如需深入了解技术细节和概念验证过程，请阅读 Noma 网站上的完整报告。原文连接：https://www.infoq.com/news/2026/07/gitlost-github-prompt-injection/