Wiz 的 AI 驱动安全研究工具发现，Snowflake 的一个公共代码库中存在一个严重漏洞，该漏洞由 GitHub Copilot 的 AI 自动修复功能在五天前无意中引入。这个漏洞允许攻击者通过提交一个特殊标题的 issue，窃取访问 Snowflake 内部 Jira 系统的凭证。此事件凸显了 AI 编程助手可能带来的新型安全风险，以及自动化工具发现和利用这些漏洞的速度之快。Snowflake 在接到报告的当天就修复了漏洞，并确认没有造成实际损失。
漏洞是如何产生的：AI 犯下的错误
Wiz 的自动化安全代理 Red Agent 在扫描 Snowflake 的 GitHub 组织时，发现其 .NET 连接器代码库中的一个工作流存在脚本注入漏洞。
- 漏洞根源： 问题出在一个名为
jira_issue.yml的 GitHub Actions 工作流中。该工作流会在新 issue 被创建时触发。 - AI 的“贡献”： 在事件发生前五天，GitHub Copilot 的 AI 自动修复功能提交了一次代码更新。这次更新旨在优化工作流，但它犯了一个致命错误。
- 错误的操作： AI 移除了原有的安全代码模式（该模式通过环境变量安全地传递 issue 标题），并将其替换为将用户输入的
issue 标题直接拼接到 shell 命令中。
换句话说，一个本应“自动修复”问题的 AI 操作，反而创造了注入漏洞的根源。
这个改动意味着，任何 GitHub 用户都可以通过创建一个包含恶意代码的 issue 标题，来控制 Snowflake 后端服务器的命令执行。
发现与利用：AI 对抗 AI
攻击者可以利用这个漏洞，通过精心构造的 issue 标题来窃取敏感信息。
- 看似存在的防护： 代码中有一个看似用于防护的
if条件，但由于其逻辑缺陷，这个条件永远为真，导致所谓的“安全门”完全敞开，任何用户都能触发该漏洞。 - 自主利用： Wiz 的
Red Agent在发现漏洞后，自动尝试利用。它构造了一个 issue 标题，该标题包含的命令可以窃取用于访问 Jira 的凭证，并通过网络回调发送出去。 - 智能调整： 初次尝试因一个简单的语法错误而失败。但
Red Agent没有就此停止，而是自主分析了错误信息，调整了其攻击载荷，最终成功执行了命令。
几秒钟内，Wiz 的服务器就收到了包含 Snowflake Jira 系统凭证的回调，该凭证拥有其内部工程、安全合规和漏洞悬赏项目的广泛读取权限。
快速响应与修复
Snowflake 的响应非常迅速，展现了高效的安全处理流程。
- 当日修复： 在 Wiz 于 2026 年 6 月 23 日报告漏洞的同一天，Snowflake 就发布了补丁，恢复了之前更安全的代码模式。
- 凭证吊销： 被泄露的 Jira 访问令牌立即被吊销并轮换。
- 审计确认： 经过详细的日志分析，Snowflake 确认在漏洞存在的 5 天窗口期内，除了 Wiz 的测试外，没有任何第三方进行过访问。
关键教训
这次事件为使用 AI 辅助开发的团队提供了宝贵的经验。
- AI 生成的代码需要严格审查： AI 工具基于概率模式生成代码，它们缺乏对历史背景的理解，可能会无意中移除为防止特定漏洞（如注入）而设计的安全措施。AI 提交的代码必须经过与人类编写代码相同的严格审查。
- 漏洞暴露窗口正在急剧缩短： 这个漏洞仅存在了五天就被自动化工具发现。这表明安全团队必须适应一个新常态：漏洞发现可能在几小时内发生，要求更快的修复周期和更短的凭证有效期。
- 为 AI 设置安全护栏： 必须建立机制，防止 AI 助手用不安全的直接字符串拼接，取代用于处理输入的结构化、安全的数据解析方法。
完整的响应与时间线
- 6 月 18 日： Copilot Autofix 引入了脚本注入漏洞。
- 6 月 23 日： Wiz 的 AI 工具发现、利用并向 Snowflake 报告了该漏洞。
- 6 月 23 日（当天）： Snowflake 修复了漏洞，恢复了安全的代码。
- 6 月 24 日： 相关的 Jira 凭证被轮换。
- 7 月 25 日： 根据 Snowflake 的披露政策，事件被公开。