攻击原理

研究人员描述的易受攻击的GitHub Agentic Workflow模式具备以下特征：

• 在 issues.assigned 事件上触发
• 读取Issue的标题和正文
• 使用诸如 add-comment 这样的智能体工具发布评论
• 运行时拥有对组织内其他仓库（包括私有仓库）的读取权限

攻击分四步进行：

1. 下饵： 攻击者在目标组织的一个公开仓库中，打开一个看似无害的GitHub Issue。
2. 注入： Issue的正文中隐藏着用自然语言编写的指令，指示AI智能体去获取私有仓库中的文件。
3. 触发： 当GitHub的自动化流程将Issue分配给智能体时，事件触发的工作流会命令智能体去执行任务。智能体在拥有访问权限的仓库（包括私有仓库）中搜索并获取数据。
4. 泄露： 智能体将获取到的内容以公开评论的形式发布在该Issue下，这意味着任何能看到该Issue的人（通常是所有人）都可能看到这些敏感数据。

根本架构缺陷

这个漏洞的核心问题在于AI智能体的上下文窗口未能严格区分系统指令和不可信的用户数据。 正如Noma公司的Sasi Levi所言：“智能体的上下文窗口就是它的攻击面。智能体读取的任何内容 —— 无论是Issue、Pull Request、评论还是文件 —— 只要智能体将其视为指令输入，就都可以被武器化。”

基于大语言模型（LLM）的智能体在数据和指令同时出现在同一个上下文或工具输出中时，很难区分它们。 这不仅仅是传统的代码漏洞，而是一种结构性的风险：当工作流没有对不可信的内容进行隔离或约束时，用户可控的文本就能直接操纵智能体的行为。

研究人员已正式将这类缺陷归类为“Agentic Workflow Injection (AWI)”，并识别出两种核心模式：Prompt-to-Agent (P2A)，即不可信内容触及智能体的提示边界；以及Prompt-to-Script (P2S)，即攻击者通过模型输出传播到后续脚本中。

绕过防护的“魔法词”："Additionally"

GitHub设置了防护栏（Guardrails）来阻止数据外泄，但Noma的研究人员发现，他们可以用一个极其简单的方法将其绕过。 在注入的指令中加入“Additionally”这个词，似乎能让模型重新“理解”输出要求，而不是拒绝执行，从而让数据泄露像任务的合法延续一样顺利进行。

这种方法与更广泛的提示注入研究结果一致，表明特定的措辞或工具返回的文本可能导致模型遵循其本不应遵循的恶意指令。 这种绕过方式与之前的一些事件（如Invariant Labs披露的GitHub MCP漏洞）中的模式如出一辙，后者也是通过一个恶意Issue劫持用户的智能体，从私有仓库中窃取数据。

给企业的防护建议

基于GitLost的发现和更广泛的智能体工作流安全指南，受影响的企业应实施以下控制措施：

• 对智能体输入采取零信任原则 —— 永远不要将用户可控的内容视为可信的指令输入，应将不可信的用户数据与核心系统提示隔离。
• 严格执行最小权限原则 —— 移除不必要的跨仓库访问权限，并限制智能体通过公开输出暴露数据的能力。
• 使用白名单机制管理工具而非黑名单，并要求在执行敏感操作（如发布外部可见评论或访问敏感仓库）时，必须经过人工审批关卡。
• 审计CI/CD和仓库自动化工作流中的AI智能体集成，特别是当不可信的GitHub事件上下文被纳入提示或智能体输入时。
• 从逻辑上隔离不可信的用户输入与系统级指令，将用户生成的内容视为不可信数据，而非权威指令。

各组织还应对智能体密钥应用最小权限原则，并实施持续的安全监控以检测提示注入攻击。

GitHub的回应（截至7月7日）

根据Dark Reading和Noma Security披露的时间线：

• Noma通过负责任的披露流程向GitHub报告了该漏洞。
• GitHub告知Noma，他们更新了与易受攻击的工作流模式相关的文档，研究人员随后确认，该易受攻击的配置已不复存在。
• 截至2026年7月7日，GitHub尚未就GitLost发布正式的公开声明或CVE编号。
• 该漏洞似乎是通过删除或修改相关文档和工作流模板来部分解决的，而非通过一个记录明确的平台级安全修复。

更大图景：系统性的风险

GitLost并非孤立事件。它代表了一类日益增长的安全漏洞：当拥有敏感数据访问权限的AI智能体暴露在不可信的用户内容面前时，风险随之而来。类似的问题已经影响了GitHub MCP集成、谷歌的Gemini CLI工作流（TrustIssues漏洞）以及Claude Code的GitHub Actions。 它们的共同点是：当数据和指令出现在同一个上下文窗口中时，LLM驱动的智能体天生缺乏区分它们的能力 —— 这是一个任何单一平台补丁都无法完全解决的根本性架构挑战。

攻击原理

研究人员描述的易受攻击的GitHub Agentic Workflow模式具备以下特征：

• 在 issues.assigned 事件上触发
• 读取Issue的标题和正文
• 使用诸如 add-comment 这样的智能体工具发布评论
• 运行时拥有对组织内其他仓库（包括私有仓库）的读取权限

攻击分四步进行：

1. 下饵： 攻击者在目标组织的一个公开仓库中，打开一个看似无害的GitHub Issue。
2. 注入： Issue的正文中隐藏着用自然语言编写的指令，指示AI智能体去获取私有仓库中的文件。
3. 触发： 当GitHub的自动化流程将Issue分配给智能体时，事件触发的工作流会命令智能体去执行任务。智能体在拥有访问权限的仓库（包括私有仓库）中搜索并获取数据。
4. 泄露： 智能体将获取到的内容以公开评论的形式发布在该Issue下，这意味着任何能看到该Issue的人（通常是所有人）都可能看到这些敏感数据。

根本架构缺陷

这个漏洞的核心问题在于AI智能体的上下文窗口未能严格区分系统指令和不可信的用户数据。 正如Noma公司的Sasi Levi所言：“智能体的上下文窗口就是它的攻击面。智能体读取的任何内容 —— 无论是Issue、Pull Request、评论还是文件 —— 只要智能体将其视为指令输入，就都可以被武器化。”

基于大语言模型（LLM）的智能体在数据和指令同时出现在同一个上下文或工具输出中时，很难区分它们。 这不仅仅是传统的代码漏洞，而是一种结构性的风险：当工作流没有对不可信的内容进行隔离或约束时，用户可控的文本就能直接操纵智能体的行为。

研究人员已正式将这类缺陷归类为“Agentic Workflow Injection (AWI)”，并识别出两种核心模式：Prompt-to-Agent (P2A)，即不可信内容触及智能体的提示边界；以及Prompt-to-Script (P2S)，即攻击者通过模型输出传播到后续脚本中。

绕过防护的“魔法词”："Additionally"

GitHub设置了防护栏（Guardrails）来阻止数据外泄，但Noma的研究人员发现，他们可以用一个极其简单的方法将其绕过。 在注入的指令中加入“Additionally”这个词，似乎能让模型重新“理解”输出要求，而不是拒绝执行，从而让数据泄露像任务的合法延续一样顺利进行。

这种方法与更广泛的提示注入研究结果一致，表明特定的措辞或工具返回的文本可能导致模型遵循其本不应遵循的恶意指令。 这种绕过方式与之前的一些事件（如Invariant Labs披露的GitHub MCP漏洞）中的模式如出一辙，后者也是通过一个恶意Issue劫持用户的智能体，从私有仓库中窃取数据。

给企业的防护建议

基于GitLost的发现和更广泛的智能体工作流安全指南，受影响的企业应实施以下控制措施：

• 对智能体输入采取零信任原则 —— 永远不要将用户可控的内容视为可信的指令输入，应将不可信的用户数据与核心系统提示隔离。
• 严格执行最小权限原则 —— 移除不必要的跨仓库访问权限，并限制智能体通过公开输出暴露数据的能力。
• 使用白名单机制管理工具而非黑名单，并要求在执行敏感操作（如发布外部可见评论或访问敏感仓库）时，必须经过人工审批关卡。
• 审计CI/CD和仓库自动化工作流中的AI智能体集成，特别是当不可信的GitHub事件上下文被纳入提示或智能体输入时。
• 从逻辑上隔离不可信的用户输入与系统级指令，将用户生成的内容视为不可信数据，而非权威指令。

各组织还应对智能体密钥应用最小权限原则，并实施持续的安全监控以检测提示注入攻击。

GitHub的回应（截至7月7日）

根据Dark Reading和Noma Security披露的时间线：

• Noma通过负责任的披露流程向GitHub报告了该漏洞。
• GitHub告知Noma，他们更新了与易受攻击的工作流模式相关的文档，研究人员随后确认，该易受攻击的配置已不复存在。
• 截至2026年7月7日，GitHub尚未就GitLost发布正式的公开声明或CVE编号。
• 该漏洞似乎是通过删除或修改相关文档和工作流模板来部分解决的，而非通过一个记录明确的平台级安全修复。

更大图景：系统性的风险

GitLost并非孤立事件。它代表了一类日益增长的安全漏洞：当拥有敏感数据访问权限的AI智能体暴露在不可信的用户内容面前时，风险随之而来。类似的问题已经影响了GitHub MCP集成、谷歌的Gemini CLI工作流（TrustIssues漏洞）以及Claude Code的GitHub Actions。 它们的共同点是：当数据和指令出现在同一个上下文窗口中时，LLM驱动的智能体天生缺乏区分它们的能力 —— 这是一个任何单一平台补丁都无法完全解决的根本性架构挑战。