Copilot Autofix 在 Snowflake 的 CI/CD 流水线中打开了 Shell 注入漏洞

一项由 GitHub 的 Copilot Autofix 编写并于 2026 年 6 月 18 日合并到 Snowflake 仓库的安全修复，去除了已消毒的输入模式，使公司的 CI/CD 流水线暴露于命令注入。五天后，一个自主的 AI 研究代理发现了该漏洞并加以利用，从 GitHub Actions 运行器中提取了有效的 Jira 凭证，Wiz Research 于 2026 年 8 月 17 日披露。

该漏洞位于 jira_issue.yml，这是位于 snowflakedb/snowflake-connector-net 的 GitHub Actions 工作流，该仓库是 Snowflake .NET 数据连接器的公共仓库。每当有人打开 GitHub issue 时，该工作流会触发，并将 issue 的标题（完全由提交者控制的文本）直接插入到 shell 脚本中。由于触发条件是 issues: opened，任何互联网上的 GitHub 账户都可以在无需身份验证的情况下触发它。

Wiz 的 “Red Agent”——一个通过 Snowflake 的 HackerOne 漏洞赏金计划运行的自主安全研究工具——标记了该工作流，构建了可用的利用代码，并从运行器的环境中导出了 Jira API 令牌。Snowflake 在收到报告的同一天（2026 年 6 月 23 日）修补了工作流，随后一天轮换了凭证，并告知 Wiz 其审计日志显示在这五天的窗口期间没有其他主体触及受暴露的系统。

“Autofix” 去除了消毒器

引入可注入模式的提交通过 PR #1218，“SNOW-2069227: 更新 jira 工作流” 合并，日期为 2026 年 6 月 18 日。该拉取请求的历史显示自 2025 年 8 月起有人工作者在处理 Jira 自动化——在过程中出现了一次由 Copilot Autofix powered by AI（GitHub Advanced Security 机器人，负责为代码扫描警报生成建议修复）的共同作者提交。

AI 建议修改了工作流处理 issue 标题的方式。原有代码通过 env: 变量传递标题，并使用 jq --arg 构建 JSON 负载，这是一种将不受信任的文本排除在 shell 之外的模式。建议的替换则放弃了该做法，改为直接字符串展开:

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

sed 转义在 GitHub 的模板引擎已经将标题替换进脚本之后才执行。标题中的单引号会跳出 echo '...' 包裹，使其后的所有内容作为 shell 执行。GitHub 官方的 Copilot Autofix 文档 将此功能描述为生成“针对警报的单一建议修复，由您自行审查并应用”——正是审查环节让该修复得以通过。

工作流还包含一个看似限制触发者的守护条件:

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

在 issue 事件中，github.event.pull_request 始终为 null，因此比较始终为 true。所有 GitHub 用户都能够通过此关卡。

利用双方各有一个代理

Red Agent 的首次数据泄露尝试失败。其负载使用了 # 注释字符来吞掉注入行的其余部分，但该注释同时消耗了 TITLE=$(...) 的右括号，导致运行器返回 bash 语法错误而未执行。根据 Wiz 的报告，代理分析了错误，重新编写负载以 ; echo ' 关闭 shell 块，并再次尝试。

有效负载以 issue 标题的形式传递，将运行器的 JIRA_API_TOKEN、JIRA_USER_EMAIL 和 JIRA_BASE_URL 环境变量进行 base64 编码，并通过 curl 发送至带外监听器。回调在几秒内从 Azure 托管的 GitHub Actions 运行器返回。

恢复的令牌以 qa@snowflake.net 身份在 snowflakecomputing.atlassian.net 上进行身份验证，拥有对 Snowflake 工程、合规安全以及漏洞赏金跟踪项目的读取权限。

Snowflake 的修复工作在 2026 年 6 月 23 日通过 PR #1402 合并，恢复了安全的 env: 变量和 jq --arg 解析模式。Jira 令牌于 2026 年 6 月 24 日被撤销并轮换。Wiz 表示已安全删除其概念验证测试期间访问的所有数据。

“Snowflake 感谢 Wiz 通过我们的漏洞披露和 HackerOne 漏洞赏金计划，对这些发现进行负责任的报告和合作，”公司在与 Wiz 报告一起发布的声明中表示。“该披露于 2026 年 6 月 23 日收到，随后立即进行了调查和修复，我们的调查未发现未经授权的访问证据。”

五天窗口揭示的内容

该披露正处于已记录模式的中心: AI 辅助的变更在审查过程中过于快速，以至于超出了安全假设。Snowflake 自己的审计日志使此次事件得以清晰呈现:它们让公司能够声明，且 Wiz 能够确认，在暴露窗口期间没有第三方访问。Snowflake 的审计日志分析证实在这五天的窗口期间没有外部第三方访问该端点。

时间线还压缩了业界一直视为假设的一个序列。编码助手删除了专门用于防止 shell 注入的防御性模式，因为助手没有该模式存在原因的记录。随后，一个攻击性代理在数天内发现并武器化了该结果，并针对实时错误输出自行修正其利用。攻击方在没有键盘前人类操作的情况下运行；而在编码方，AI 生成了变更，但由人类审查并合并了该建议——这正是审查环节失效的地方。

Wiz 的报告建议 AI 生成的拉取请求应经过与人工代码相同的静态分析，团队应缩短凭证的生命周期以匹配自动化发现的速度，并且应通过防护措施阻止代理用直接字符串插值取代结构化解析器。Check Point 在今年夏初将 AI 流量的提示检查迁移至企业防火墙，而 Unite.AI 已报道了代理沙箱逃逸以及代理系统在进攻方成熟时达到真实生产目标的情况。Snowflake 事件是从 CI 流水线内部讲述的同一故事:漏洞持续了五天，之所以它被视为案例研究而非泄露通知，仅在于哪个代理先到达。