Cybersecurity researchers at Wiz have discovered a new GitHub Actions flaw in a public Snowflake repository: snowflakedb/snowflake-connector-net. By using a specially crafted GitHub issue—not through a pull request—attackers could trigger command injection inside a workflow that uses CI/CD automation, while exposing internal JIRA credentials.
The incident mainly affects how the workflow processes data from issues and then passes it directly into a shell command execution path. In this article, we explain what went wrong, how the researchers were able to exploit the issue, and which lessons your organization can apply to its own software supply chain.
What exactly is the GitHub Actions flaw?
The vulnerability was in a specific workflow: .github/workflows/jira_issue.yml. This workflow ran when a user created a public issue. In that same workflow path, values such as JIRA_BASE_URL, JIRA_USER_EMAIL, and JIRA_API_TOKEN were passed to a subsequent step.
According to Wiz, the problem was that the workflow used issue fields provided by the attacker (title and body) directly inside a shell run block. As a result, those values could end up being executed as though they were trusted input.
Wiz also identified a logical mistake in the conditional logic: the workflow checked github.event.pull_request.user.login even though the event type was an issue. In that scenario, GitHub indicates that referencing a non-existent property results in an empty string. In this context, that comparison therefore didn’t block a normal issue as intended.
Command injection via crafted issues
The core of the exploit was command injection within CI/CD. Instead of only viewing or manipulating information, an attacker could influence how a shell command was constructed within the workflow.
Wiz describes that their Red Agent system, during authorized security testing, first tried a payload that ended in a shell-syntax error. Then the system adjusted its approach—and the injection worked.
After that, the researchers received an out-of-band callback from the GitHub Actions runner. This detail is important: it indicates that the runner performed actions outside the normal workflow path—exactly the kind of behavior you want to detect when CI/CD is abused.
Why were JIRA credentials an extra risk?
The workflow exposed JIRA data to a step that would process the injected input. Wiz states that it ultimately managed to obtain the Jira API token used by the workflow.
The token found by Wiz was associated with qa@snowflake.net. With that token, read access and visibility were possible for Jira projects including engineering, security compliance, and bug bounty tracking on snowflakecomputing.atlassian.net.
Important nuance: Wiz and Snowflake do not provide a fully public list of which permissions applied at workflow level. However, both parties indicate that audit and run details are not public. That means the exact impact isn’t fully transparent, although the risk of token exposure in CI/CD is clearly evident.
No confirmed compromise, but a fix and token rotation
Snowflake responded to the report and implemented a fix. In its statement—reproduced by Wiz—Snowflake said there was no evidence of unauthorized access.
At the same time, Wiz reports that Snowflake rotated the affected Jira token on June 24, 2026. This is a standard response for credential-related findings: even if you can’t prove a misuse occurred, you want to eliminate the threat.
Snowflake also said its review did not find any other unwanted external usage during the exposure period. Wiz notes that the underlying audit logs are not public, so outside the involved teams, the scope remains limited to these statements.
Timeline: when the flaw was introduced and when it was fixed
Wiz tied the vulnerable workflow to the time it landed on the default branch. According to the research, that was on June 18, when a pull request (number #1218) was merged into place via a squash merge.
The fix followed soon after. Wiz says Snowflake received the issue report via HackerOne, and that the solution was merged on June 23, 2026 in pull request #1402.
On June 23, a change was made that replaced the original interpolation of issue data with a safer path: Snowflake removed the direct expansion of GitHub expressions from the vulnerable step and instead used environment variables passed as arguments to jq. This reduces how directly the input reaches the critical shell execution path.
Wiz also states that the corrected handling remains available in the repository’s master branch.
Why “it doesn’t always work” when you check PR fields
A valuable lesson from this story is the workflow’s conditional check. Wiz found that it was looking at fields associated with a pull request (such as github.event.pull_request.user.login), while the workflow actually started based on the issue event.
GitHub indicated that in such a case, dereferencing a property that doesn’t exist results in an empty string. The consequence is that the comparison didn’t function as the intended security gate. For security teams, this means that a logic bug in conditions can be just as serious as the input handling itself.
Relation to earlier GitHub warnings
Wiz references a GitHub documentation item from July 2025, which describes a class of workflow injection. At the time, GitHub explicitly warned against directly expanding untrusted issue or input data in run: blocks and advised using intermediate environment variables.
This advice closely matches what Snowflake did in pull request #1402: the approach changed from direct interpolation to controlled passing through environment variables, followed by processing with a tool such as jq.
Did this receive a CVE?
As of August 17, 2026, Wiz reported that, based on available information, it had not found a CVE or a CVSS score, and there was no mention in the CISA Known Exploited Vulnerabilities (KEV) catalog. No connector release update linked to the finding was identified either.
However, Wiz says that the vulnerable interpolation no longer appears on the master branch. In addition, Wiz states that the primary source materials do not show evidence of a proven exploit in the wild or a known customer compromise.
Practical lessons for your own CI/CD
Even if you don’t work directly with Snowflake connectors, this is a scenario you can map to your own pipelines. If your CI/CD workflows process issue- or user-generated content, pay extra attention to the following:
- Avoid direct shell interpolation: don’t pass untrusted input “1-to-1” into a shell run command.
- Use controlled variables: rely on environment variables and a clear data-structure processing flow (such as jq with arguments) so your input can’t be interpreted as code.
- Validate your event logic: ensure workflow conditions match the event type (issue vs. pull request). An incorrect property check can undermine security.
- Minimize credential exposure in workflows: only pass tokens to steps where they are strictly needed.
- Monitor and rotate if there’s doubt: even without proof of misuse, token rotation is an effective way to limit damage.
Want more context on this kind of supply-chain risk and how attacks spread through development and automation chains? Read our piece on a supply chain attack via LiteLLM and see which patterns show up there around dependencies and pipeline behavior.
Conclusion: a CI/CD injection you shouldn’t underestimate
The GitHub Actions flaw in the Snowflake repository shows how quickly pipeline automation can turn into an attack surface. By using crafted issue data directly inside a shell run block, researchers were able to test command injection—made even more complex by the fact that JIRA credentials were part of the workflow path.
Snowflake resolved the root of the problem by restructuring how the input was handled and rotating the affected token. Although, according to available information, there is no evidence of successful unauthorized access outside the testing scope, the key signal remains: CI/CD is code, and external input should be treated as potentially adversarial data.
By testing your workflows for direct interpolation, event conditions, and credential hygiene, you reduce the chance that a similar pattern leads to command injection again.
Source: https://thehackernews.com/2026/08/snowflake-github-actions-flaw-lets_0330881554.html
