Wiz’s Red Agent Found a Snowflake GitHub Actions Flaw Five Days After It Went Live

The Snowflake incident was a GitHub Actions workflow-injection flaw in the public snowflakedb/snowflake-connector-net repository—not a vulnerability in the .NET connector shipped to customers. A change merged on June 18, 2026 placed an attacker-controlled GitHub issue title inside a shell command. Five days later, Wiz’s autonomous Red Agent discovered the weakness and used it in an authorized HackerOne exercise to extract credentials for Snowflake’s internal Jira.

What changed in Snowflake’s workflow

The vulnerable code was in .github/workflows/jira_issue.yml, a workflow triggered whenever a GitHub issue was opened. PR #1218, titled “SNOW-2069227: Update Jira workflows,” replaced a safer pattern—passing the issue title through an environment variable and using jq to construct JSON—with direct interpolation of

${{ github.event.issue.title }}

That distinction mattered. GitHub expands the expression before the shell executes the command. A malicious issue title containing a single quote could therefore close the intended quoted string and add shell commands of the attacker’s choosing. Sanitizing the value afterward with sed could not undo the earlier shell interpretation.

The workflow’s

issues: opened

The commit credited “Copilot Autofix powered by AI” as a co-author, and its AI-assisted review did not flag the problem. But the evidence does not establish whether Copilot generated the unsafe change or reviewed a human-authored change. The careful conclusion is that Copilot was associated with the change and failed to catch the injection—not that model authorship is conclusively proven.

How Red Agent found the vulnerability

Wiz’s Red Agent scanned Snowflake’s public GitHub organization for risky CI/CD patterns. It identified the Jira workflow as using untrusted issue data inside a shell run: block and inferred that a specially crafted public issue title could produce arbitrary command execution on the GitHub-hosted Actions runner.

On June 23—five days after the vulnerable change was merged—the agent opened a crafted issue as part of Snowflake’s HackerOne vulnerability-disclosure program. The title escaped the shell string and caused the workflow to send Jira credentials to an out-of-band callback controlled for the authorized proof of concept.

This was a sanctioned security test rather than an uncontrolled intrusion. The important security finding was nevertheless real: a public issue could reach a workflow step that handled credentials and turn ordinary issue creation into command execution.

What access the exploit exposed

The compromised workflow had access to Snowflake’s internal Jira configuration, including the Jira URL, user email, and API token. The recovered token was associated with qa@snowflake.net; Wiz used it to authenticate to the internal Jira portal and assess the potential exposure.

Reporting described read access to Jira projects covering engineering, security compliance, and bug-bounty activity. The supplied evidence does not establish the token’s complete permission set or provide a definitive inventory of every record that could be reached, so the strongest supported conclusion is that it enabled access to sensitive internal Jira content rather than unrestricted access to Snowflake systems.

The vulnerable asset was the repository’s CI/CD automation. No affected released Snowflake Connector for .NET version was reported, because the flaw was in the GitHub Actions workflow rather than in the connector’s runtime code.

Snowflake’s response

Wiz reported the issue on June 23. Snowflake remediated the workflow that day and rotated the exposed Jira credential the following day.

Snowflake then reviewed audit logs and concluded that Wiz was the sole actor during the exposure window. Wiz also said it securely deleted the proof-of-concept data it had accessed.

No unauthorized third-party access was reported, no CVE assignment was reported, and no affected connector release was identified. Those limits describe the confirmed impact; they do not make the original workflow design safe. A public issue title should never have been allowed to become part of a shell command in a workflow that handled internal credentials.

The CI/CD lesson

The practical lesson extends beyond Snowflake and Copilot. GitHub expressions such as issue titles, pull-request titles, branch names, and comments should be treated as hostile input whenever they cross into a shell command.

Safer workflow design includes:

• Passing untrusted values through environment variables rather than interpolating them directly into run: scripts.
• Using structured tools such as jq to build JSON instead of assembling shell strings.
• Quoting and validating data at the shell boundary.
• Keeping credentials out of steps that process attacker-controlled content whenever possible.
• Reviewing AI-generated security changes as carefully as any human-authored code.

The episode is a concise demonstration of an emerging security problem: one AI-assisted coding system can miss a dangerous CI/CD change, while an autonomous offensive agent can find and validate it within days. Automation can accelerate both remediation and exploitation—but it does not replace independent review.