AI生成的GitHub Copilot自动修复引入漏洞，Wiz Red Agent攻入Snowflake内部Jira

Wiz Red Agent发现并利用了一个由GitHub Copilot Autofix引入的GitHub Actions漏洞，验证了对Snowflake内部Jira中敏感数据的访问权限，并评估了爆炸半径——全程无需人工干预。

作为通过Snowflake的HackerOne漏洞披露计划进行的持续安全研究的一部分，Wiz Research的“Red Agent”——一种自主的、AI驱动的安全研究工具——在Snowflake的一个公共仓库中识别出了一个关键的GitHub Actions工作流漏洞。

这一事件凸显了软件开发中一个快速显现的现实：AI编码助手如何无意中引入工作流注入漏洞，以及自动化AI智能体如何迅速在真实环境中发现这些漏洞。

Wiz于2026年6月23日负责任地披露后，Snowflake当天修复了该漏洞，轮换了受影响的凭据，并通过详细审计日志验证Wiz是暴露窗口期间的唯一行为者。Wiz确认，概念验证测试期间访问的所有数据均已安全删除。

执行摘要：Wiz Red Agent在snowflakedb/snowflake-connector-net中识别出一个脚本注入漏洞。

该问题允许未经认证的用户通过打开一个标题经过特制构造的GitHub issue，在GitHub Actions runner中执行任意命令。

关键的是，该漏洞于2026年6月18日——即发现前五天——通过一个由AI驱动的Copilot Autofix共同编写的提交（PR #1218）引入。AI助手删除了仓库现有的净化输入模式，并将其替换为shell脚本中的直接字符串展开。

暴露过程：发现阶段，Wiz Red Agent的CI/CD能力扫描了Snowflake的GitHub组织，并标记了snowflakedb/snowflake-connector-net中的jira_issue.yml工作流，该工作流因在run:

块中使用了不可信输入而存在脚本注入风险。该工作流在issues:opened事件上触发——意味着任何GitHub用户都可以通过打开一个issue来触发它——并将攻击者控制的issue标题直接插入到shell脚本中：run:

| TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")。

sed转义在GitHub模板展开之后运行，标题中的单引号可以跳出echo '...'并允许任意命令执行。它删除了仓库现有的安全模式，该模式通过env:变量传递issue标题并使用jq构建JSON负载。

相反，它使用了上述直接的${{ github.event.issue.title }}插值。换句话说，一个AI“自动修复”提交创建了注入向量。

敞开的“安全门”：该工作流有一个看似具有保护性的if:条件：然而，对于issues事件，github.event.pull_request始终为null。因此该条件简化为（null != 'whitesource-for-github-com[bot]'）。

这始终为真，每个GitHub用户都能通过这一门禁。

利用阶段：我们构造了一个issue标题，在模板展开后，跳出echo字符串并通过带外回调泄露Jira凭据：关键的是，当Red Agent的cicd能力最初尝试使用标准注释字符（#）进行数据外泄时，runner返回了一个bash语法错误，

因为注释消耗了TITLE=$(...)的闭合括号。Red Agent没有停止或失败，而是：自主分析了语法执行错误；调整了其负载，使用;echo '来正确闭合shell块；

几秒钟内，我们的监听器收到了来自GitHub Actions runner（Azure IP 20.106.182.197）的回调，其中包含base64编码的凭据。

注意：我们的第一次尝试使用#来注释掉该行的其余部分，这导致了意外的EOF bash错误，因为它也消耗了TITLE=$(...)的闭合括号。修复方法是使用;echo '来正确闭合shell语法。

泄露的token以qa@snowflake.net身份认证到snowflakecomputing.atlassian.net，授予了对Snowflake工程、安全合规和漏洞赏金跟踪项目的读取访问权限。

修复与取证：同日修补——Snowflake于2026年6月23日修补了该工作流（1dc7766，PR #1402），完全恢复了安全的env:变量和jq --arg解析模式。凭据撤销：相关的JIRA token已被撤销并轮换。

取证验证：全面的审计日志分析确认，在5天暴露窗口期间，没有外部第三方访问该端点。所有异常查询均与Wiz的测试IP严格匹配。关键要点：AI代码生成需要严格监督——AI编码工具基于概率模式预测代码，可能无意中重新引入已弃用或不安全的shell模式。

AI生成的PR必须接受与人类代码相同的静态分析和安全审查。发现窗口的缩短——该漏洞仅存在五天就被自动化智能体发现并验证。安全运营必须适应自动化发现以小时计的环境，需要快速的补丁周期和短时有效的凭据。

防止AI安全回归——自动化AI助手通常缺乏关于为何选择特定代码模式的历史背景。在此事件中，一个自动化PR删除了一个明确为防止shell注入而实现的安全env: + jq解析模式。安全团队必须实施护栏，阻止AI智能体用直接字符串插值替换结构化数据解析器。

披露时间线：2026年6月18日——脚本注入模式在jira_issue.yml中由提交4a1b8ce（PR #1218）引入，该提交由AI驱动的Copilot Autofix共同编写。

2026年6月23日——Wiz通过HackerOne识别、利用并向Snowflake报告了该漏洞（报告编号3819931）。2026年6月23日——向Snowflake安全团队发送Slack通知。

2026年6月23日（同日）——Snowflake修补了易受攻击的脚本注入工作流（提交1dc7766，PR #1402），恢复了安全的env: + jq --arg模式。2026年6月24日——Jira token轮换。

2026年7月25日——公开披露截止日期（根据Snowflake的披露政策，6月25日解决后30天）。Snowflake的回应：Snowflake感谢Wiz通过我们的漏洞披露和漏洞赏金计划HackerOne对这些发现进行负责任地报告和协作。

Wiz Research报告了Snowflake一个公共GitHub仓库中的安全漏洞。该披露于2026年6月23日收到，并立即进行了调查和修复，我们的调查未发现未经授权访问的证据。保护我们的系统仍是首要任务，我们致力于不断加强我们的软件开发和安全管理实践。

我们正在与Wiz合作，与更广泛的行业分享这些经验教训，以鼓励广泛采用这些安全最佳实践。