Wiz Research 的红队 Agent 搞了个大新闻：它用完全自主的方式，通过 GitHub Actions 模板注入漏洞，拿下了 Snowflake 的内部 Jira 实例。

更让人不安的是，这个漏洞的引入者不是人类开发者，而是 GitHub Copilot 的 Autofix 功能。

攻击链条

Snowflake 的某个仓库里有一个 GitHub Actions workflow，用 issues.event_name 做条件判断来控制 PR 的构建流程。这本身没什么问题——直到 Copilot Autofix 介入。

Copilot 在一次代码扫描中建议了一个安全修复：把 issues.event_name 赋给一个环境变量，然后拿这个变量去跟字符串比较。修复的意图是好的——防止表达式注入。但问题是，Copilot 生成修复代码时，把这个环境变量直接塞进了 run: 脚本里，而 issues.event_name 的内容是攻击者可控的。

于是 Wiz 的 Red Agent 创建了一个 Issue，标题里嵌入了 shell 命令。这个标题流经 issues.event_name → 环境变量 → run: 脚本，在 GitHub Actions runner 上以 Snowflake 的身份执行了。

从那里开始，Red Agent 提取了 runner 上的 GitHub token，用它在 Snowflake 的另一个内部仓库里创建了恶意 PR，进一步渗透到了 Jira 的 CI/CD 管道，最终拿到了 Jira 实例的访问权限。

整个过程，Red Agent 没有写一行 exploit 代码。它自己规划了攻击路径，自己决定每一步做什么，像人类渗透测试者一样根据上一步的结果调整下一步的策略。

Copilot 背锅？

把锅全扣在 Copilot 头上是不公平的。真正的问题出在 GitHub Actions 的设计模式上：在 run: 脚本里嵌入外部可控变量，这件事本身就是危险的，不管是谁写的代码。

但 Copilot Autofix 确实在这里扮演了一个催化剂的角色。它看到了一个安全问题，试图修复它，但修复的方式引入了更大的问题。AI 理解"把变量赋给环境变量可以防止注入"这个规则，但它不理解"这个环境变量接下来会被用到 shell 脚本里，所以注入风险并没有消失，只是转移了"。

这正是当前 AI 编码工具的核心局限：它们擅长模式匹配和局部修复，但缺乏对整个系统安全边界的全局理解。

社区反应

这件事在 Hacker News 社区引发了激烈讨论。核心观点集中在几个方向：

一部分人认为这暴露了 AI 辅助编码的深层矛盾——AI 降低了代码生成的成本，但审查成本没有同步下降。"AI 能在 8 小时内完成 40 小时的工作量，但之后你需要花 40 小时修复它产生的 bug。"

另一部分人把矛头指向了 GitHub Actions 本身的设计。run: 字段里嵌 shell 脚本，配合 ${{ }} 表达式注入，这种模式本身就极其危险。有评论推荐使用 zizmor 这样的静态分析工具来扫描 Actions 配置，也有人建议干脆把 CI/CD 配置当作生产代码来对待——所有变更都需要完整的 code review。

Wiz 的博客文章里有一个细节值得注意：Snowflake 的漏洞现在已经被修复了，但修复方式不是关掉 Copilot Autofix，而是在 workflow 层面加了更严格的输入过滤。一个漏洞被堵上了，但产生这个漏洞的机制——AI 生成安全修复代码、人类信任并合入——还在继续运转。

这才是最值得警惕的地方。

参考来源：

• Wiz Blog: Red Agent Exploits Snowflake Vuln Missed by GitHub Copilot
• HN 讨论