🔒 安全 · 漏洞预警

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

Noma Security 发现一种名为 GitLost 的提示注入漏洞，攻击者只需在公开 GitHub Issue 中嵌入隐藏指令，就能诱骗 AI Agent 泄露私有仓库数据。全程无需任何编程技能、访问权限或凭据。

综合公开信息整理• 2026年7月• 全文约 3 分钟读完
#GitHub #AI Agent #提示注入 #GitLost #安全漏洞
0 级 攻击所需技能 · 无需编程 / 凭据
1 个 触发词「Additionally」绕过防护
2 类 受影响仓库 · 公开 + 私有

⚡ 30 秒速览

  • 漏洞名称：GitLost，由 Noma Security 发现并披露，攻击者零门槛即可利用。
  • 攻击方式：在公开 GitHub Issue 中嵌入隐藏指令，AI Agent 读取后自动执行，将私有数据写入公开评论。
  • 关键细节：仅用关键词 "Additionally" 就绕过了 GitHub 的防护机制，模型将其误判为"当前任务的延续"。
  • 行业定性：被多位安全专家称为 "Agentic AI 的 SQL 注入"——一种系统性、覆盖整个类别的漏洞类型。

01GitLost 漏洞全景 一个 Issue 引发的数据泄露

Noma Security 研究团队发现，GitHub 新推出的 Agentic Workflows 功能存在一个危险的提示注入漏洞。攻击者只需在一个公开仓库中创建一个 Issue，并在正文中嵌入隐藏指令——当 Agent 被触发执行时，它会读取 Issue 内容，然后按照攻击者的指令，将私有仓库中的敏感数据写入公开评论。

整个攻击链路清晰得令人不安：

创建公开 Issue→嵌入隐藏指令→Agent 被触发→读取私有仓库→数据写入公开评论

注：Agent 通过 issues.assigned 事件触发，自动读取 Issue 标题和正文，并使用 add-comment 工具发布回复。攻击者全程无需任何特殊权限。

一个更值得警惕的细节：防护机制形同虚设。

Noma 表示，尽管 GitHub 已经部署了严格的防护机制，但攻击者仅仅使用了 "Additionally" 这个衔接词，就触发了模型的非预期行为。Agent 访问了本应受限制的私有文件，并将其内容完整地发布在公开评论中。有效载荷本身没有变化，只是这个词让防护机制将其从"新的指令"重新归类为"当前任务的延续"。

0所需攻击技能
1触发词数量
2仓库类别
∞潜在影响范围

注：攻击者不需要任何编程技能、访问权限或凭据，只需在一个配置了 Agentic Workflows 的公开仓库中创建 Issue 即可。影响范围取决于 Agent 被授予的跨仓库权限。

02信任边界为何失效 传统安全模型碰到 Agent 天花板

传统安全模型假设，信任边界由代码负责维护。而在 Agentic 系统中，信任边界部分依赖于模型的行为——而模型天然具备遵循指令的特性。这带来一个根本性转变：

传统安全模型

信任边界由代码和权限控制维护。用户输入与系统指令严格分离，注入攻击通过参数化查询等手段可防可控。

Agentic 安全模型

信任边界部分依赖于模型行为。用户输入即指令，模型无法区分"该做什么"和"用户说了什么"，提示注入成为系统性难题。

对于 Agentic AI 来说，提示注入攻击正在变成类似 Web 应用中的 SQL 注入问题——一种系统性的、覆盖整个类别的漏洞类型，需要同样系统化的策略和防御措施。

但问题远不止于技术层面。

正如安全社区指出的那样：私有仓库从来就不是真正的安全边界——它只是组织边界。当读取代码的是你雇佣的人类时，这个边界成立；但当读取代码的是一个 Agent 时，这个假设被彻底打破了。如果一个 Agent 能访问你的私有仓库，那么其中所有内容都距离公开泄露只差一个精心构造的 Issue。

03社区怎么看 四位安全从业者的直言

🏢 Vijendra Malhotra · Fractional CTO核心判断

  • 私有仓库从来都不是安全边界。它实际上是组织边界——只有当读取你代码的人都是你雇佣的人类时，这个边界才成立。
  • Agent 打破了这一假设。如果一个 Agent 能访问你的私有仓库，请把其中所有内容都视为距离公开泄露只差一个精心构造的 Issue。
观点来源：LinkedIn 公开评论 · 经编辑提炼

🧑‍💻 Significant_Sea_4230 · Reddit技术洞察

  • 危险之处并不在于 Agent "很聪明"，而在于它可能连接了过多上下文、过多仓库，或者拥有权限过于宽泛的 Token。
  • 权限的过度授予是根本原因，而非模型本身的能力问题。
观点来源：Reddit 公开讨论 · 经编辑提炼

🔍 cH3332xr · 安全研究者关键细节

  • 这里最有意思的细节是 "Additionally" 绕过机制。有效载荷本身并没有改变，只是这个衔接词在防护机制看来，把它从"新的指令"重新归类成了"当前任务的延续"。
  • 这是一个决策边界问题，而不是内容问题。防护机制不是在判断"有没有恶意"，而是在判断"是不是同一件事"。
观点来源：Reddit 公开讨论 · 经编辑提炼

🧠 mcv · Hacker News终极类比

  • SQL 注入之所以产生，是因为系统把用户输入当成了指令的一部分，而不是原本应该被视为纯数据的内容。将两者分离之后，这个问题就解决了。
  • 而提示注入无法避免，因为用户输入本身就是指令。这是 Agentic 系统的先天属性，不是可以修补的漏洞。
观点来源：Hacker News 公开讨论 · 经编辑提炼

04如何防御 Noma 研究人员的四条建议

面对这种系统性的提示注入风险，Noma 研究团队给出了具体可操作的防御策略：

  • 用户控制的内容永远不应被视为可信指令。将用户输入与系统指令严格隔离，在提供给模型之前进行适当的清理和上下文分离。
  • Agent 权限应限制在严格必要的范围内。拥有跨仓库访问权限的 Agent 会成为极具价值的攻击目标，遵循最小权限原则。
  • 限制 Agent 可公开披露的信息范围。尤其是在响应 Issue 内容时，应明确划定哪些信息可以写入公开评论，哪些必须保持内部。
  • 重新审视信任边界。在 Agentic 系统中，信任边界不再由代码单方面维护，模型行为本身也是信任链的一部分，需要纳入安全审计范围。

注：上述建议综合自 Noma Security 研究报告及多位安全专家的公开评论，具体实施需结合组织实际架构。

编辑核心判断

提示注入不是 Agent 的 bug，而是 Agent 的 feature。当"遵循指令"成为模型的核心能力，用户输入即指令这个事实就无法改变。真正的防线不是让模型学会拒绝，而是让系统架构不再需要模型来做安全决策。