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

InfoQ 中文 2026-07-31T17:44:35.216636

安全公司 Noma Security 近期披露了一种名为 GitLost 的提示注入攻击手法。攻击者只需在公开 GitHub Issue 中嵌入一句隐蔽指令,就能让 GitHub 的 AI Agent 读取并泄露私有仓库的数据。这一事件再次提醒开发者:Agent 的权限边界和输入隔离,是当前最需要重视的安全设计问题。

GitLost 是什么?

GitLost 是 Noma Security 发现的一种提示注入漏洞利用方式,目标直指 GitHub 新推出的 Agentic Workflows。所谓 Agentic Workflows,是 GitHub 提供的一种自动化机制,可以配置 AI Agent 在特定事件(如 Issue 被指派、提交代码等)发生时自动执行任务。这本来是提升开发效率的功能,但如果配置不当,就会成为数据泄露的入口。

Noma Labs 复现了这样一个存在漏洞的工作流配置:它会在 issues.assigned 事件触发时运行,读取 Issue 的标题和正文,然后通过 add-comment 工具发布一条回复评论。关键问题在于,这个 Agent 同时拥有读取组织内其他仓库(包括公开仓库和私有仓库)的权限。

攻击如何得逞:无需任何权限,只用一条 Issue

攻击者根本不需要掌握编程技能,也不需要任何访问凭据。他只要在目标组织所属的某个公开仓库里创建一个 Issue,然后等待即可。

Noma 团队表示,尽管 GitHub 已经为 Agentic Workflows 部署了严格的防护机制,但在这场攻击中,仅仅使用关键词 “Additionally” 就触发了模型的非预期行为。模型随即访问了一个原本受限制文件的内容,并将其发布在公开评论中。也就是说,一条看似普通的句子,就完成了从“公开输入”到“私有数据泄露”的跳跃。

为什么一个词就能绕过防护?

这背后的核心是提示注入(Prompt Injection)问题。简单来说,AI Agent 在处理输入时,会把用户提供的内容和系统指令混在一起,而模型天然倾向于“遵循指令”。攻击者可以通过精心构造的语句,让模型误以为恶意指令是当前任务的延续,而不是新的、需要防范的指令。

社区用户 cH3332xr 的评论很到位:

这里最有意思的细节是 “Additionally” 绕过机制,有效载荷本身并没有改变,只是这个衔接词在防护机制看来,把它从“新的指令”重新归类成了“当前任务的延续”。这是一个决策边界问题,而不是内容问题。

换句话说,防护系统试图区分“数据”和“指令”,但攻击者用简单的过渡词就能模糊这条边界,让模型把攻击者的话当作任务的一部分来执行。

安全专家:Agent 系统的信任边界已经变了

Noma 在报告中指出了这一问题的本质:

传统安全模型通常假设,信任边界由代码负责维护。而在 Agentic 系统中,信任边界部分依赖于模型的行为,而模型天然具备遵循指令的特性。对于 Agentic AI 来说,提示注入攻击正在变成类似 Web 应用中的 SQL 注入问题:一种系统性的、覆盖整个类别的漏洞类型,需要同样系统化的策略和防御措施。

他们还特别强调了一个容易被忽视的事实:

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

危险之处并不在于 Agent “很聪明”。而在于它可能连接了过多上下文、过多仓库,或者拥有权限过于宽泛的 Token。

社区观点:提示注入为什么躲不掉?

在 Hacker News 的讨论中,用户 mcv 把问题上升到了更普遍的层面:

SQL 注入之所以产生,是因为系统把用户输入当成了指令的一部分,而不是原本应该被视为纯数据的内容。将两者分离之后,这个问题就解决了。而提示注入无法避免,因为用户输入本身就是指令。

这个类比很直观:传统编程语言中,数据和指令可以严格分开;但大语言模型的输入本身就是指令的载体,你无法真正“清理”掉所有恶意意图,又保留正常使用。

防御建议:别把用户输入当可信指令

针对这类风险,Noma 的研究人员给出了几点明确建议:

详细的技术分析和概念验证过程,可参考 Noma 官网发布的完整报告。

在 AI 编程工具越来越普及的今天,这个漏洞是一个及时的提醒:Agent 越强大,权限越需要谨慎。代码生成只是表面,底层的数据访问权限和指令边界,才是真正决定安全与否的地方。

关键要点

查看原文