Noma Labs 的研究人员展示了 GitHub 最新发布的 Agentic Workflows 可以被诱导发布私有仓库文件，这表明仅凭一条公开的 issue 评论，就能将内部 AI 助手变成数据泄露的渠道。

该漏洞之所以重要，是因为它可以在不使用任何特殊漏洞利用代码的情况下绕过 GitHub 内置的安全检查；攻击者只需要构造一个看似无害的 issue，让 AI agent 读取并执行即可。

该漏洞的工作原理

Agentic Workflows 允许 AI agent 通过执行 workflow 文件中定义的命令来响应 GitHub 事件（例如新 issue）。Noma Labs 发现，该 agent 无法区分合法的 workflow 指令与用户提交评论中嵌入的文本。通过发布一个模仿经理请求并附加隐藏指令的公开 issue，攻击者可以引导 agent 执行以下操作：

  1. 打开该 issue（公开可见）。
  2. 包含一行看似普通但含有隐蔽命令的内容。
  3. 触发 AI 从该 workflow 被允许读取的私有仓库中获取文件。
  4. 让 agent 将获取的内容作为该 issue 的回复发布。

研究人员发现，在隐藏命令前插入“Additionally,”这一个单词就足以绕过 GitHub 的防护机制。不需要额外的权限、token 或自定义代码——只需要恰当的措辞。

这不仅仅是一个漏洞

这个问题是结构性的。AI agent 会将从仓库事件中接收到的任何文本视为可信的，这实际上使用户生成的内容成为了类似于 Web 应用程序中 SQL 注入的输入向量。如果一个 workflow 授予了 agent 读取私有仓库的权限以及公开评论的能力，两者的结合就为数据外泄创造了直接路径。

GitHub 的回应

GitHub 已收到有关此漏洞的通知。

团队的缓解措施

  • 限制 agent 权限：仅在绝对必要时才授予对私有仓库的读/写权限。
  • 阻止公开发布：配置 workflow，使 agent 无法在公开 issue 中发布评论或其他产物。
  • 将所有外部输入视为不可信：添加验证层，在用户生成的内容到达 AI 之前对其进行清洗或忽略。
  • 审计 workflow 触发器：审查哪些事件（issue、pull request 等）会调用 agent，并验证相关权限是否与预期用途相符。

核心结论： 一个既能读取私有代码又能公开发布内容的 AI 助手，其安全性完全取决于你为其设置的边界。如果没有严格的权限限制和输入清洗，一个公开的评论就能将一项生产力功能变成数据泄露的路径。