事件经过
GitHub Copilot Autofix 在一次提交（2026年6月18日）中共同编写了针对公开仓库 snowflakedb/snowflake-connector-net 的代码，该提交删除了 GitHub Actions 工作流（jira_issue.yml）中安全的环境变量/jq 输入清理模式，并将其替换为攻击者控制的 GitHub issue 标题的直接字符串插值到 shell run: 代码块中，加上一个在 issue 事件上始终评估为真的损坏 'if' 保护条件。五天后，Wiz 的自主进攻安全 AI 代理（'Red Agent'）在对公开仓库的例行扫描中发现了脚本注入漏洞，精心设计了一个恶意 issue 标题来突破 shell 字符串限制并通过带外回调泄露 Jira 凭据，获得了对 Snowflake 在 Atlassian 上的工程、安全合规和漏洞赏金跟踪项目的读取访问权限。
影响分析
这是一个具体的、公开记录的案例，展示了 AI 代码助手（Copilot Autofix）向广泛使用的仓库引入安全回归，以及独立的自主 AI 攻击代理在数天内发现并武器化该漏洞——始终没有任何一方的人工指导。它表明 AI 编写的代码更改可以在伪装为清理的情况下静默删除安全控制，而进攻性 AI 代理已经在以机器速度针对公开 AI 接触的供应链进行操作。尽管这发生在经过批准的 HackerOne 漏洞赏金计划中（Snowflake 同日修补、轮换凭据），但基础故障模式——AI 助手引入的漏洞 + AI 代理速度的利用——对于未经批准的攻击者同样适用。
攻击途径
攻击者（或在本案例中，经批准的研究代理）在公开仓库上打开一个具有精心设计标题的 GitHub issue；issue 标题在 GitHub Actions 工作流中的 shell run: 代码块中未经清理地展开（绕过了始终为真的保护条件），从而实现了脚本注入和从运行器泄露凭据。
受影响系统
GitHub Copilot Autofix 修改的 CI/CD 工作流（snowflakedb/snowflake-connector-net GitHub Actions）；Wiz Red Agent（自主 AI 安全研究代理）
缓解措施
始终通过 env: 变量而不是在 run: 代码块中直接插值来传递不可信的事件数据（issue 标题、PR 正文等）；审计 AI 助手编写的 CI/CD 更改以查找是否删除了安全模式；针对触发类型的实际事件模式验证保护条件。请参阅 Wiz Research 博客：https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug