The short answer
On June 18, 2026, a commit co-authored by GitHub Copilot Autofix introduced a script-injection flaw into a GitHub Actions workflow in Snowflake’s public snowflake-connector-net repository. Five days later, Wiz’s autonomous Red Agent independently discovered the bug, exploited it to extract an internal Jira token, and filed a responsible disclosure. Snowflake patched and rotated the token the same day. The full account was published on August 17, 2026. GitHub disputes that Copilot authored the vulnerable code. The incident is a clean case study in how AI-assisted development and AI-powered security scanning now operate in parallel — and why teams cannot rely on either alone.
What happened: a timeline
June 18, 2026. A commit lands in the snowflakedb/snowflake-connector-net public GitHub repository. The commit modifies a GitHub Actions workflow and is marked in git history as co-authored by “Copilot Autofix powered by AI.” Buried in the change is a shell run: step that interpolates ${{ github.event.issue.title }} directly into a bash command — a classic script-injection pattern.
June 23, 2026. Wiz Red Agent, an autonomous AI security research bot running continuously against public open-source repositories enrolled in Snowflake’s HackerOne vulnerability disclosure program, flags the workflow. The agent opens a crafted GitHub Issue with a title containing injected shell code. The Actions runner executes the payload, exfiltrating a Jira OAuth token from the runner’s environment variables. The agent uses the token to confirm access to Snowflake’s internal Jira and to assess the blast radius — all without human intervention. Notably, the agent encountered a shell syntax error on its first attempt, analyzed the failure, reformulated the payload, and succeeded on the second attempt.
Wiz filed the report through HackerOne later that day. Snowflake patched the workflow, rotated the compromised Jira token, and confirmed via audit logs that Wiz was the only actor during the five-day exposure window. No production customer data was reachable through the token.
August 17, 2026. Wiz published a full technical write-up on its blog. Forbes and The Hacker News covered the disclosure the same day.
The vulnerability: GitHub Actions script injection
The flaw class is well-documented but persistently common: a GitHub Actions run: step that interpolates a context expression — in this case ${{ github.event.issue.title }} — directly into a shell command. When an attacker controls the issue title, they control the injected string. The Actions runner executes it with access to whatever secrets and tokens the workflow has mounted.
In Snowflake’s case, the Jira token was available to the runner through a repository secret. Once exfiltrated, it granted read access to Snowflake’s internal Jira, which could contain project roadmaps, security incident tickets, and customer escalation records. The fix is straightforward: assign the context value to a named environment variable and reference the env var in the shell command. Context expressions are interpolated before the shell sees the string; env vars are not.
This pattern appears in workflows that process user-controlled strings — issue titles, PR descriptions, comment bodies — and it frequently escapes human code review because reviewers focus on application logic rather than CI/CD plumbing. Automated security scanning of workflow files is the reliable mitigation.
Copilot’s role — and the dispute
Wiz’s account, supported by a screenshot of the git commit metadata, shows the vulnerable commit listed as co-authored by “Copilot Autofix powered by AI.” That attribution is how GitHub labels commits where its Autofix feature suggested or applied a code change. Wiz did not claim Copilot wrote the entire commit; it noted that the AI’s contribution was present in the change that introduced the flaw.
GitHub subsequently issued a statement saying its internal review found that the code was authored by a human and that Copilot did not contribute to or review the vulnerable portion. The Wiz CTO addressed the dispute publicly, standing by the commit metadata while acknowledging that determining the exact boundary between human and AI authorship in a co-authored commit is technically ambiguous.
The specific attribution question is secondary to the broader point: when AI coding tools and human engineers both touch a file, the resulting commit may carry mixed provenance. Security review processes that treat a commit as “human-written” because a human merged it miss the AI-generated portions. Review tooling needs to catch the vulnerable pattern regardless of who or what wrote it.
What it means for US & EU software teams
AI coding tools change the attack-surface profile of CI/CD workflows. Copilot, Claude Code, Cursor, and similar tools are now routine contributors to workflow files, not just application code. Workflow files have a distinct threat model — they execute in a privileged runner environment with access to repository secrets, org-level tokens, and cloud credentials — but they receive less scrutiny in code review than application logic. Teams need to explicitly extend their security review criteria to cover AI-suggested changes in .github/workflows/.
AI security agents are a real capability, not a proof-of-concept. Wiz Red Agent found this bug five days after introduction, before any human reviewer flagged it, and exploited it autonomously including self-correcting a syntax error. This is the operational capability: continuous, autonomous scanning at a cadence that no human security team can match on open-source dependencies and public repositories. Teams building or consuming open-source components should expect that both friendly and adversarial AI agents are actively probing those repositories.
Responsible disclosure timelines are compressing. The gap between vulnerability introduction and discovery in this case was five days. Traditional 90-day disclosure windows assume weeks or months before a flaw is found. When autonomous agents operate continuously, the practical exposure window before discovery — by a researcher or an attacker — is much shorter. This compresses the time available to patch before an adversarial agent finds the same bug.
For FinTech and HealthTech teams, CI/CD credentials are a compliance boundary. A Jira token that reaches internal ticketing systems containing GDPR-regulated customer data, HIPAA-covered health records, or PCI-scoped payment system details is a compliance incident, not just a security event. The Snowflake case ended cleanly because Wiz disclosed responsibly. An adversarial agent would not.
AI tools in your CI/CD workflow? Get a security review.
Our engineers conduct penetration testing and security audits that explicitly cover GitHub Actions workflows, runner secret exposure, and AI-assisted code changes. We identify the script-injection patterns that human review and standard linting miss, and we deliver a remediation roadmap in two to four weeks.
Request a CI/CD security auditWhat dev teams should do now
| Action | Timeline | Notes |
|---|---|---|
Audit .github/workflows/ for direct context-to-shell interpolation | This week | Search for ${{ github.event.issue, ${{ github.event.pull_request, ${{ github.event.comment inside run: steps; replace with env var intermediaries |
| Enable GitHub code scanning and Dependabot secret scanning | This sprint | GitHub’s built-in workflow scanning catches common injection patterns; secret scanning push protection blocks accidental token commits |
| Review AI-suggested changes to workflow files separately from application code | This sprint | Add a review step that specifically evaluates Copilot, Claude, or Cursor suggestions in .github/workflows/ against OWASP’s GitHub Actions security guidance |
| Scope runner secrets to minimum necessary permissions | Next sprint | Tokens with write access to internal systems should not be available in workflows triggered by external events (issue creation, PR from fork, comment); use environment-level secrets with required reviewers instead |
Add pull_request_target and issue_comment triggers to your threat model | Next sprint | These triggers run in a privileged context but can be activated by external contributors; they are the primary vector for this class of attack |
| Test your CI/CD attack surface with a red-team exercise | Next quarter | Manual audit misses what automated agents catch; a structured red-team covering workflow injection, secret exfiltration, and supply-chain entry points closes the gap |
Sources: Wiz Blog — Red Agent Exploits Snowflake Vuln Missed by Github Copilot (Wiz, August 17, 2026); Forbes — GitHub Copilot Missed A Vulnerability That Wiz’s AI Agent Found (Forbes, August 17, 2026); The Hacker News — Snowflake GitHub Actions Flaw Lets Crafted Issues Trigger Command Injection (The Hacker News, August 2026).
FAQ
What vulnerability did Wiz find in Snowflake’s GitHub repository?
Wiz Red Agent found a GitHub Actions script-injection vulnerability in Snowflake’s snowflake-connector-net repository. A workflow step used ${{ github.event.issue.title }} directly in a shell run: command. An attacker who opened a GitHub Issue with a specially crafted title could inject arbitrary shell commands into the Actions runner, which then executed with access to repository secrets — including a Jira token granting access to Snowflake’s internal Jira.
What role did GitHub Copilot Autofix play in introducing the flaw?
The June 18, 2026 commit that introduced the vulnerable workflow step was co-authored by “Copilot Autofix powered by AI,” according to the git history cited by Wiz. GitHub subsequently disputed this characterization, stating after an internal review that the change was authored by a human and that Copilot did not contribute to or review the vulnerable code. The dispute reflects a broader challenge: as AI suggestions and human edits intermingle in production commits, attributing responsibility for a flaw becomes harder.
How did Wiz Red Agent exploit the vulnerability?
Wiz Red Agent autonomously opened a GitHub Issue with a crafted title containing injected shell commands. When the vulnerable Actions workflow processed the issue, it executed the payload, which exfiltrated the Jira token from the runner’s environment. The agent then used the token to verify access to Snowflake’s internal Jira and assessed the blast radius — all without human involvement. The agent also self-corrected a shell syntax error on its first attempt before succeeding.
What should development teams do to prevent GitHub Actions script injection?
Three concrete steps: (1) Never interpolate GitHub context values like ${{ github.event.issue.title }}, ${{ github.event.pull_request.title }}, or ${{ github.event.comment.body }} directly into shell run: commands — assign them to an environment variable first and reference $ENV_VAR in the shell. (2) Enable GitHub’s code-scanning workflows and secret-scanning push protection. (3) Audit all existing workflows for direct context-to-shell interpolation — this pattern is common and often overlooked by both human reviewers and AI coding assistants.
Was Snowflake’s production data exposed in the Wiz incident?
No. Snowflake confirmed through detailed audit logs that Wiz Red Agent was the only actor during the five-day exposure window between June 18 and June 23, 2026. No production customer data was reachable via the compromised Jira token. Snowflake patched the workflow and rotated the token on the same day Wiz filed its HackerOne disclosure, June 23, 2026.