AI 写的修复补丁引入了漏洞：Red Agent 攻破 Snowflake Jira 的完整过程

原文来源：Wiz Research — AI 编码助手引入的注入漏洞，被自主安全研究 agent 在五天内发现并利用，最终拿到了 Snowflake 的 Jira 凭据。

一个由 AI 制造的漏洞

2026 年 6 月，Wiz Research 的"Red Agent"——一个完全自主、由 AI 驱动的安全研究工具——在 Snowflake 的公开 GitHub 仓库里发现了一个严重的 GitHub Actions 工作流漏洞。这个漏洞允许任何未认证的用户通过提交一个精心构造标题的 Issue，在 GitHub Actions runner 上执行任意命令。

真正让这件事值得关注的不是漏洞本身，而是它的来源：这个漏洞是五天前由 Copilot Autofix 引入的。

在 PR #1218 中，AI 助手把仓库原有的安全输入清洗模式删掉了，换成了在 shell 脚本里直接展开字符串。换句话说，一个 AI"自动修复"提交，创造了注入向量本身。

漏洞细节：安全模式是如何被破坏的

受影响的是 snowflakedb/snowflake-connector-net 仓库里的 jira_issue.yml 工作流。这个工作流在 issues: opened 事件时触发——意味着任何 GitHub 用户都能通过开一个 Issue 来触发它。

原本的安全写法是这样的：通过 env: 变量传递 Issue 标题，再用 jq 构造 JSON 载荷：

env:
  ISSUE_TITLE: ${{ github.event.issue.title }}
run: jq -n --arg title "$ISSUE_TITLE" ...

Copilot Autofix 把这段改成了这样：

run: TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\'/g")

问题出在 sed 转义发生在 GitHub 模板展开之后。标题里的单引号可以逃出 echo '...' 的字符串包裹，从而执行任意命令。

更讽刺的是，工作流里还有一个看起来像安全门禁的 if: 条件：

if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

但在 issues 事件中，github.event.pull_request 永远是 null。所以条件化简为 null != 'whitesource-for-github-com[bot]'——永远为真。每个 GitHub 用户都能通过这个"安全门禁"。

Red Agent 的自主攻击过程

Red Agent 构造了一个 Issue 标题，在模板展开后逃出 echo 字符串，通过 out-of-band 回调把 Jira 凭据外泄出去。

过程中有一个值得注意的细节：Red Agent 第一次尝试用 # 注释符外泄时，runner 返回了 bash 语法错误——因为注释符把 TITLE=$(...) 的右括号也吃掉了。但 Red Agent 没有停止，而是：

1. 自主分析了语法执行错误
2. 调整载荷，改用 ; echo ' 来正确闭合 shell 块
3. 成功收到了 out-of-band 回调

几秒钟内，监听器就收到了来自 GitHub Actions runner（Azure IP 20.106.182.197）的回调，里面包含 base64 编码的凭据。

这个外泄的 token 以 qa@snowflake.net 身份认证到了 snowflakecomputing.atlassian.net，获得了 Snowflake 工程、安全合规和漏洞赏金跟踪项目的读取权限。

修复与取证

Wiz 于 6 月 23 日通过 HackerOne 负责任地披露了漏洞。Snowflake 当天就修复了工作流（PR #1402），完全恢复了安全的 env: + jq --arg 解析模式，并轮换了被泄露的 Jira token。

审计日志确认：在 5 天的暴露窗口内，没有任何第三方访问过该端点，所有异常查询都严格匹配 Wiz 的测试 IP。

三个关键启示

AI 代码生成需要严格审查

AI 编码工具基于概率模式预测代码，可能无意中重新引入已废弃或不安全的 shell 模式。AI 生成的 PR 必须经过与人类代码相同的静态分析和安全审查。这次事件里，AI 移除的 env: + jq 模式恰恰是当初为了防注入而明确实现的。

发现窗口急剧缩短

漏洞存活了只有五天，就被自动化 agent 发现并验证了。安全运营必须适应"自动化发现以小时计"的新现实，需要更快的补丁周期和短期凭据。

防止 AI 安全回归

自动化 AI 助手往往缺乏"为什么当初选择了某个代码模式"的历史上下文。这次事件中，一个自动 PR 移除了专门为防止 shell 注入而实现的模式。安全团队需要建立护栏，阻止 AI agent 用直接字符串插值替换结构化数据解析器。

观察：AI 与安全的军备竞赛

这个案例最值得玩味的地方在于：漏洞制造者是 AI，漏洞发现者也是 AI。Copilot Autofix 五天内制造了一个注入向量，而 Red Agent 自主完成了从扫描、构造载荷、试错、调整到成功利用的完整攻击链条。

AI 安全研究 agent 的价值在于速度和规模化——Red Agent 可以同时扫描整个 GitHub 组织的工作流、寻找可利用模式、构造攻击载荷，而这些在传统安全研究中需要安全研究员数天甚至数周的时间。而 AI 编码助手把"引入漏洞"的成本降到了零——任何人按下"自动修复"都可能埋下隐患。

对于使用 AI 编码工具的开发团队，这次事件给出的建议很直接：AI 生成的变更要当作陌生人的贡献来审查，尤其是涉及 shell、权限和凭据处理的代码。安全护栏和代码审查不是可选项，而是 AI 进入工程流程后的必需品。