Snowflake CI/CD Flaw Opens Door to Issue-Based Injection

Security researchers at Wiz have uncovered a serious weakness in Snowflake's public CI/CD automation, where a specially crafted GitHub issue could slip past built-in guards and trigger arbitrary commands inside a workflow that holds live Jira credentials. The finding, disclosed Tuesday, exposes a subtle but dangerous gap in how organizations wire issue tracking into their build pipelines.

A workflow meant to triage, turned into a launchpad

The flaw lived in .github/workflows/jira_issue.yml in the snowflakedb/snowflake-connector-net repository. That workflow was designed to run whenever a public issue was opened, presumably to automate some Jira-related bookkeeping. But it did so by inserting the issue's title and body directly into a shell run: block, with no sanitization or parameterization. That meant an attacker who could open a GitHub issue against the public repository could inject their own shell commands into the workflow's execution.

Even more concerning, the same workflow step had access to JIRA_BASE_URL, JIRA_USER_EMAIL, and JIRA_API_TOKEN — the keys to Snowflake's Jira kingdom. The entire credential set sat in the same environment as the vulnerable command execution, making it trivial for an injected payload to exfiltrate them.

A guard that was never really there

Part of what made this attack possible was an oversight in how the workflow checked whether the issue came from a trusted bot. The workflow attempted to verify github.event.pull_request.user.login, but the event triggering the workflow was an issue, not a pull request. GitHub's documentation explains that "if you attempt to dereference a nonexistent property, it will evaluate to an empty string." So the check against whitesource-for-github-com[bot] was effectively comparing an empty string, allowing any ordinary issue through to the job.

Red Agent's in-the-field test

Wiz didn't just spot the hole in theory — its automated Red Agent system exercised it during authorized security testing. The first attempt at injection hit a shell syntax error, but the system adapted its payload and tried again. This time, the researchers received an out-of-band callback from the GitHub Actions runner, which gave them the Jira API token the workflow was using.

The token belonged to qa@snowflake.net and granted read access to Jira projects covering engineering, security compliance, and bug bounty tracking on snowflakecomputing.atlassian.net. The underlying Jira permissions, workflow run details, and audit records are not public, so the full blast radius remains unseen.

A quick fix, but a window before it

Wiz reported the flaw through HackerOne on June 23, 2026, as report #3819931. Snowflake moved fast: a fix was merged the same day in pull request #1402, swapping the direct GitHub expression expansion for environment variables passed to jq as arguments. That change closes the injection vector by keeping untrusted issue data out of the shell command string entirely.

But the vulnerable workflow hadn't been living on the default branch for long. It was merged just five days before the report, on June 18, via pull request #1218. Whether any malicious issue slipped through in that narrow window is a question Snowflake has addressed in its own way.

Snowflake's response and the token's fate

Snowflake said in a statement reproduced by Wiz that "our investigation found no evidence of unauthorized access." Wiz confirmed that the Jira token was rotated on June 24 and that Snowflake's review found no unrelated external use of it during the five-day exposure window. Still, Snowflake's underlying audit logs have not been made public, so there's no way to independently verify that claim.

Copilot's role in the flaw

Wiz pinned part of the blame on GitHub Copilot Autofix, but the commit history paints a more nuanced picture. The explicit Copilot co-authored commit, 6d0e2fa, changed jira_close.yml, not the vulnerable jira_issue.yml. That file's unsafe refactor appears in a separate August 25, 2025, commit, 094038e, attributed to sfc-gh-hpathak. Both changes later got folded into the June 18 squash merge commit 4a1b8ce, which lists Copilot Autofix among its co-authors. So Copilot was definitely in the room, but not necessarily the one who wrote the dangerous lines.

Known pattern, repeated

This isn't a novel attack class. GitHub itself documented workflow injection in July 2025, explicitly warning developers against expanding untrusted issue data directly inside run: blocks and recommending intermediate environment variables as a safer pattern. That advisory clearly didn't make it to the Snowflake workflow when it was written.

As of August 17, 2026, there is no CVE, no CVSS score, and no CISA Known Exploited Vulnerabilities (KEV) catalog entry for this issue, and no connector release has been tied to it. The vulnerable interpolation is gone from the master branch, and the available evidence does not establish malicious exploitation in the wild or customer compromise.

Why this matters

This episode is a reminder that CI/CD pipelines are prime targets for attackers, and even seemingly small misconfigurations — a workflow that trusts untrusted data, a guard that checks a property that doesn't exist — can expose sensitive credentials. For organizations that rely on GitHub Actions, the lesson is to treat every input from external actors as untrusted and to avoid embedding secrets in the same step that processes that input. Snowflake's quick fix is reassuring, but the fact that the flaw existed in a widely used open-source project, even briefly, underscores how easy it is for these mistakes to slip into production automation. It also suggests that other repositories might be making the same mistake, and a review of their workflow definitions could prevent a similar incident.