安全公司 Wiz 于 8 月 17 日发布研究称，其自主进攻安全代理发现并利用了 snowflakedb/snowflake-connector-net 公开仓库中一个 GitHub Actions 工作流里的脚本注入漏洞，并借此窃取了一个可读取 Snowflake 内部 Jira 的令牌。
时间线异常紧凑
该漏洞在 PR #1218 于 2026 年 6 月 18 日合并时上线。Wiz 在 6 月 23 日识别、利用并通过 HackerOne 报告了这一问题；Snowflake 当天就在提交 1dc7766 中修补了漏洞，并于 6 月 24 日轮换了 Jira 令牌。暴露时间只有 五天。该令牌以 qa@snowflake.net 身份对 Snowflake 的 Atlassian 租户进行认证，获得了对工程、安全合规和漏洞赏金跟踪项目的只读访问权限。
常见说法哪里说错了
这则故事正在被传播为“AI 写出了漏洞，另一套 AI 利用了它”。这种对称说法，是没人能为之背书的部分。GitHub 向记者表示，引发该漏洞的代码贡献由人类作者完成，既未经过 Copilot 审阅，也未由其参与。Wiz 自己的帖子末尾附带更新，承认尚不清楚这次代码改动是否由 AI 辅助，并指出 Copilot Autofix 在那次拉取请求中的已知贡献，是对另一个文件的一个独立修复。因此，作者归属的说法遭到供应商质疑，也被研究人员留有余地——但带来报道热度的，正是这一说法。
无争议的发现更严重
没有人争论的是：一名自主代理在无人协助下完成了整条攻击链——侦察、发现可注入的工作流、利用漏洞、外泄凭证，并横向移动进入另一个 SaaS 系统——目标还是一家大型数据平台供应商。而无论是谁写下了这个漏洞，GitHub 自己的扫描都没有在合并前将其标记出来。这是关于防御覆盖的一个发现，与作者归属争议完全无关。
哪些被触达了，哪些没有
还有一种第三种失真也值得点名。这是一个公开连接器仓库的 CI 工作流，获取到的是对 Jira 项目的只读访问权限。它不是 Snowflake 数据平台，也不是客户数据。Snowflake 表示，其调查没有发现除研究人员之外的任何未经授权访问，审计日志显示 Wiz 是端点上唯一的第三方。“Snowflake 遭入侵”和“通过 Actions 运行器读取 Jira”并不是同一句话。