Wiz红队AI发现Copilot Autofix引入Snowflake漏洞 GitHub否认AI参与

2026年6月18日，Snowflake的snowflakedb/snowflake-connector-net仓库中，一次PR合并将一个存在脚本注入风险的GitHub Actions工作流带入生产。PR #1218修改了jira_issue.yml文件，把issue标题直接插入shell命令的echo语句中，sed转义操作发生在GitHub模板展开之后。任何用户只需提交包含单引号的issue标题，即可突破引号限制执行任意命令。

漏洞形成机制

原有安全做法是将issue标题存入环境变量，再用jq构建JSON。修改后直接使用模板插值，攻击者可构造payload让命令在runner上执行。Wiz的Red Agent在6月23日通过HackerOne项目扫描发现此问题，并成功提取Jira令牌，访问工程与合规项目。Snowflake当天完成修复并轮换凭证，审计日志显示暴露期间仅Wiz访问。

GitHub Advanced Security扫描了最终PR版本，却未标记该注入风险。

AI工具链的验证断层

Copilot Autofix在PR中被记录为共同作者，对jira_close.yml的修改进行了检查，但未识别jira_issue.yml的注入模式。GitHub事后内部审查称，引入漏洞的代码变更由人类完成，未经过Copilot审查或贡献。此说法与Wiz报告中“Copilot Autofix共同署名”的描述存在差异。

事件核心在于现有安全扫描工具对AI辅助生成的代码缺乏针对性检查。模板插值与shell转义的顺序问题属于经典注入模式，却未被自动工具捕获。Red Agent则在漏洞上线后迅速完成从语法错误分析到有效payload调整的全过程。

产业层面的连锁影响

AI编码工具已进入实际开发流程，Copilot Autofix的目标是自动修复扫描发现的问题。但当修复本身引入新漏洞，且后续扫描未能检测时，信任链出现断裂。开发者可能默认AI建议经过验证，实际却依赖人工二次审查。

• CI/CD流水线成为高价值攻击面，任意用户可通过公开issue触发执行。
• 自主安全代理能在数天内完成发现与利用，远快于传统人工流程。
• GitHub与第三方AI安全工具对同一代码变更的判断出现分歧，暴露评估标准不一致。

类似案例显示，AI生成代码的执行路径与人工编写的代码在安全审查上应采用同等或更高标准。当前工具链在处理模板插值、环境变量与命令构造的组合时，存在盲区。

后续判断

该漏洞的引入与发现过程表明，AI辅助开发的实际安全边界取决于扫描工具对新代码模式的覆盖程度。GitHub否认AI参与的具体贡献，但无法改变工作流已被修改并上线的事实。未来需要针对AI生成片段建立独立验证流程，而非仅依赖现有静态分析规则。