AI 安全 Agent 发现 Snowflake CI/CD 脚本注入漏洞

2026 年 8 月 17 日，Wiz Research 披露其自主安全工具 "Red Agent" 在 Snowflake 的一个公开仓库 snowflakedb/snowflake-connector-net（.NET 数据连接器）中发现了脚本注入漏洞，并利用该漏洞从 GitHub Actions 运行器中窃取了一个有效的 Jira API 令牌。该漏洞于 2026 年 6 月 18 日随一个 pull request 合并而暴露，Red Agent 在五天后发现了它。这五天的窗口期就是整个故事的核心。

CI/CD 中的脚本注入，是指工作流将攻击者可控制的文本——这里是 GitHub issue 的标题——直接拼入 shell 命令。由于该工作流在 issues: opened 时触发，互联网上的任何账户都可以在未认证的情况下触发它——只需提交一个精心构造标题的 issue。

受影响的工作流 jira_issue.yml 将 ${{ github.event.issue.title }} 直接插入了 run: 块。一个 guard 条件看似在起保护作用，但比对的是一个在 issue 事件上始终为 null 的 pull request 字段，所以它总是求值为 true，每个用户都通过了检查。Red Agent 的第一个窃取载荷抛出了 bash 语法错误；智能体读取错误输出后，重写了载荷以正确关闭 shell 块，并在重试时成功了。几秒钟后，来自 Azure 托管运行器的回调抵达，带来了一个 base64 编码的令牌，该令牌以 qa@snowflake.net 身份认证，对 Snowflake 工程、安全合规和 bug-bounty 相关的 Jira 项目具有读取权限。Wiz 于 6 月 23 日通过 Snowflake 的 HackerOne 计划报告了该漏洞，Snowflake 当天即完成修复，次日轮换了令牌；其审计日志显示在此窗口期间 Wiz 是唯一的行动者。没有造成实际损害。

一个广泛流传的说法当天就被推翻。Wiz 最初将漏洞代码归咎于 GitHub 的 Copilot Autofix。GitHub 进行了内部审查并驳回了这一说法：它表示导致该漏洞的贡献来自人类编写，Copilot Autofix 既没有审查也没有参与这些修改。Wiz 更新后的文章将 Copilot Autofix 有记录的贡献放在了同一 pull request 的另一个文件中，但仍声称 Copilot 检查了合并后的变更并称其为清晰——这正是 GitHub 质疑的那一半。Wiz 当晚更新文章称"该代码变更是否由 AI 辅助尚不明确"，《The Register》也修正了标题。AI authorship 的角度站不住脚了；但自主 exploitation 的那半仍然成立。

为什么脚本注入问题不断进入生产环境？

这个机制很古老，修复方案也有文档记录，所以它反复出现的部分才值得深思。GitHub 自身的 Actions 安全指南给出了明确的补救措施：将不可信输入通过中间 env: 变量传递，而不是直接拼入 shell，这样模板引擎就无法用输入构建命令。Wiz 发布了 diff：安全模式——env: 加 jq --arg——在该工作流合并前存在，合并后消失了。安全意图原本在那里，然后一次重构移除了它；而按照 Wiz 的说法，GitHub Advanced Security 分析了最终版本，包括有漏洞的工作流，但没有标记出注入。

这就是结构性缺口，而且与框架无关：防御模式编码了"为什么"，而编辑操作通常保留了代码"做什么"却丢失了"为什么"。无论变更的作者是人还是什么，review 步骤才是应该捕获被移除的防护逻辑的地方，但它没有。Pull request 以一个绿色对勾合并了。

第二个结构性转变发生在攻击者一侧，这也是让第一个变得紧迫的原因。Wiz 自己的结论是，发现窗口正在急剧收缩——安全运营现在必须以小时计而非周计来规划自动化发现。这里的五天，进攻侧没有人类在键盘前——智能体扫描了代码、构建了漏洞、遇到错误、针对实时输出进行了诊断、然后自我修正。一个假设——新引入的 CI 缺陷有数周的隐蔽期供人探测——已经不再成立。这里的发现是自动化的，而审查不是。

团队现在应该检查什么？

第一，堵住这个特定的漏洞。将所有不可信输入——issue 标题、PR 标题、分支名、commit 信息——通过中间环境变量路由，绝不直接 ${{ }} 插值到 run: 块内部。这是 GitHub 有文档记录的建议，是一个机械性的改动。

第二，缩短凭证生命周期以匹配自动化发现速度。一个存活数月的令牌是智能体有足够时间找到并使用的令牌；短生命周期、最小权限的凭证缩小了任何单一泄露工作流的爆炸半径。

第三，将 AI 编写和 AI 辅助的 CI 变更视为需要与任何其他变更同等审视的变更——因为这类回归是通过审查步骤而非建议步骤渗透的。将工作流文件置于 CODEOWNERS 之后，让指定审阅者签署对 .github/workflows 的修改，并启用专门覆盖 Actions 的代码扫描。

第四，对你的智能体提出一个更难的问题：当一个智能体执行写路径操作——合并 PR、调用内部 API、操作工单系统——该操作是有门控且被记录的，还是就这样发生了？这里被利用的路径是一个 CI 运行器，而非智能体工具调用。但发展方向正是智能体通过工具执行这类操作，而治理问题无论哪种情况都是一样的。

Waxell 如何处理相邻问题

要准确说明 Waxell 在这里会做什么和不会做什么。被利用的路径是 GitHub Actions 运行器执行 shell 命令——不是 MCP 工具调用——所以 Waxell 产品线中没有任何组件位于该路径上，它不会阻断这次注入或这次窃取。仓库层面的控制——env: 模式、分支保护、CODEOWNERS、短生命周期令牌——才是关闭此次事件的手段。

Waxell 治理的是相邻且不断增长的攻击面：AI 智能体发出的工具调用。当一个编码或助理智能体通过 MCP 工具执行写路径操作——合并 pull request、发布到工单系统、调用内部 API——Waxell MCP Gateway 在上游看到请求之前，以及在结果返回之后，会针对租户的策略规则对该调用进行评估。需要审批的调用会被暂停而非丢弃：gateway 保持连接打开，这样智能体不会超时，审阅者批准后调用恢复，或拒绝后智能体收到一个可恢复的结构化错误——同一种必须在审批疲劳中存活下来才算真实的人类在环模式。每一次代理的调用都解析为真实用户身份，审计日志记录调用、决策和触发的规则——无载荷、可持久保存多年、可导出为 CSV。策略规则变更在 30 秒内生效。

有两个范围限制是这次事件值得明确指出的。Gateway 治理穿越它的调用；持有直接上游凭证的智能体，或在 CI 运行器内部运行的进程，处于该路径之外。Gateway 不判断一个操作是否安全——它强制要求需要审批的调用等待有记录的人类决策，并留下一条归属记录。对于你在 Python 中构建的智能体，Waxell Observe 在运行内部应用相关策略逻辑，这样低置信度或超出策略的步骤可以在下一步执行前被升级，而不是事后检查。

其价值不在于检测这个 bug。而在于当写路径操作通过受治理的工具调用运行时，"哪个智能体在什么策略下做了这件事，谁批准了它"有了一个答案——与 Snowflake 审计日志在这里给出的答案相同，只是范围限定在智能体发出的调用上。

Snowflake CI/CD 漏洞是什么？

snowflakedb/snowflake-connector-net 公开仓库中的一个 GitHub Actions 工作流 jira_issue.yml，将 GitHub issue 的标题直接插入了 shell 命令。由于该工作流在任何人员打开 issue 时触发，任何未认证用户都可以用精心构造的标题在运行器上执行任意命令。Wiz 的自主 Red Agent 利用它窃取了 Jira API 令牌。

GitHub Copilot 编写了有漏洞的代码吗？

这个说法被推翻了。Wiz 最初将有漏洞的变更归咎于 Copilot Autofix，但 GitHub 进行了内部审查并表示导致该漏洞的贡献是人类编写，Copilot Autofix 既没有审查也没有参与。Wiz 更新后的文章将 Copilot Autofix 有记录的贡献放在了同一 pull request 的另一个文件中。Wiz 更新文章称该变更是否由 AI 辅助尚不明确。没有争议的是，一个自主 AI 智能体发现并利用了该漏洞。

漏洞暴露了多长时间？

五天。可注入模式在 pull request 于 2026 年 6 月 18 日合并时生效，Wiz 的 Red Agent 于 6 月 23 日发现并报告了它。Snowflake 在报告当天修复了漏洞，次日轮换了受影响的令牌。

GitHub Actions 脚本注入的推荐修复方案是什么？

GitHub 自身的指导是将不可信输入通过中间 env: 变量传递，而不是直接插值到 run: 块中，这样值作为数据处理而非用于构建 shell 命令。结合最小权限、短生命周期令牌以及对工作流文件的 CODEOWNERS 审查，可以关闭常见路径。

Waxell 能阻止这次事件吗？

不能。被利用的路径是 CI 运行器执行 shell 命令，这不是 MCP 工具调用，也不穿越 Waxell 的 gateway；仓库层面的控制才是关闭此次事件的手段。Waxell 治理的是另一个表面——智能体发出的工具调用——MCP Gateway 可以在审批策略后门控写路径调用，并保留归属审计记录。

---

Wiz (Wiz Research)，"Red Agent Exploits Snowflake Vuln Missed by Github Copilot"（含 Snowflake 当日声明及 2026 年 8 月 17 日 19:57 UTC 更新），2026 年 8 月 17 日

The Register (Jessica Lyons)，"An AI failed to detect a bug in Snowflake's code. Then another AI agent exploited it"（标题及报道于 2026-08-18 修正），2026 年 8 月 17 日

The Hacker News (Swati Khandelwal)，"Snowflake GitHub Actions Flaw Lets Crafted Issues Trigger Command Injection"，2026 年 8 月

The Next Web (Ana Maria Constantin)，"GitHub disputes Wiz's claim that Copilot Autofix wrote a Snowflake flaw"，2026 年 8 月 18 日

GitHub Docs，"Secure use reference"（GitHub Actions 中脚本注入的缓解措施）

最初发表于 Waxell 博客。

五天窗口期论证的是治理智能体做什么，而不只是它们建议什么。从免费使用 Waxell MCP Gateway 开始——一个受治理的端点，带有审批策略和归因审计日志，记录你的智能体已发出的工具调用。