Copilot Autofix 漏洞实录：AI 生成的 Issue 如何 bypass 代码审查，偷走 Snowflake 凭据
2026 年 6 月 23 日，Wiz 通过 Snowflake 的 HackerOne 项目披露了一个漏洞。五天后的 6 月 28 日，他们再次提交报告——这次不是人做的，是他们的 AI 红队工具 Red Agent 自主完成的。
整个过程没有一个人工干预。从发现漏洞、构造攻击 payload、到验证凭据泄露，全部由 AI 自动完成。
漏洞是怎么被发现和利用的
Wiz 的 Red Agent 在 Snowflake 的一个公开 GitHub 仓库里，发现了一个 GitHub Actions workflow 的安全问题。这个 workflow 在每次 issue 创建时会自动触发，并使用 Copilot 的 Autofix 功能来生成修复建议。
问题在于：workflow 没有对 issue 内容进行充分的 sanitized 处理。
Red Agent 构造了一个特殊的 issue title。这个 title 在模板展开后，会 break out 出 echo 字符串，然后通过 out-of-band callback 把 Jira 凭据外泄。
整个攻击链：
恶意 Issue Title
→ GitHub Actions workflow 触发
→ 模板引擎展开（没做 sanitize）
→ Copilot Autofix 自动 review 并 approve
→ workflow 执行，凭据被回传到攻击者服务器
关键细节：Copilot 的 AI review 没有识别出这个 issue 标题是恶意的。它把整个 attack 当作正常的代码修复建议接受了。
为什么 AI Code Review 会中招
这不是第一次 AI 代码审查被绕过。核心问题在于：
Copilot 的 review 模型被训练为"帮助开发者写代码"，而不是"检测恶意输入"。
当 AI 看到一段 workflow 代码，它会优先关注"这段代码怎么改进"，而不是"输入数据有没有被污染"。这种目标函数的偏差，让注入攻击有了可乘之机。
另一个因素是 context window 的限制。workflow 文件可能很长，AI review 时可能只关注了改动部分，忽略了上下游的 context。
Snowflake 的响应
Snowflake 的反应是标准的：当天就修复了漏洞，轮换了两阶段受影响的凭据，并通过审计日志确认——在暴露窗口期内，只有 Wiz 的 Red Agent 访问过这些数据。
Snowflake 在回应中说：“Snowflake 感谢 Wiz 通过 HackerOne 漏洞披露计划进行的负责任的报告和协作。”
对其他团队的警示
这个案例有几个值得每个开发团队注意的点：
1. GitHub Actions 的 issue 触发器要 sanitize
如果你的 workflow 被 issue 事件触发，永远不要信任 issue 标题或正文的内容。做 input validation，对特殊字符转义。
2. 自动化 code review 工具不能替代安全审查
Copilot、Cursor、Claude Code 这些工具在辅助编码方面很强，但它们的目标函数是"写代码"，不是"审安全"。安全审查还是要人来做，或者有专门的安全工具（如 Semgrep、CodeQL）来补位。
3. 凭据管理要分层
即使一个 workflow 被利用，也不应该让整个团队的 Jira 凭据暴露。用角色化的 service account、缩短凭据 TTL、做访问范围限制。
4. 考虑引入 AI 红队测试
Wiz 的 Red Agent 证明了 AI 自主发现漏洞的可行性。如果你的应用依赖 AI 辅助的开发流程，定期用类似的工具做 penetration testing 是合理的。
这件事意味着什么
AI 正在改变安全攻防的格局。一方面，AI 辅助的安全研究（如 Red Agent）能让漏洞发现更快、更全面；另一方面，攻击者也可以用 AI 来绕过传统的 defense。
对开发团队来说，最实际的建议是：用 AI 提升效率没问题，但安全边界要由人来守住。 特别是当你的 pipeline 里有 AI 自动 decision-making 的环节时，要清楚它的盲区在哪里。