Snowflake’s public snowflakedb/snowflake-connector-net repository has been identified as vulnerable to GitHub Actions workflow injection. This vulnerability could be exploited to trigger command execution within CI/CD workflow through specially crafted GitHub issues. In this case, the flaw is attributed to the repository’s automatic workflow, jira_issue.yml, which runs automatically when a public issue is opened.
When processing issue data, the workflow exposed Jira credentials, including API tokens, to the affected job. Attacker-controlled issue titles and descriptions were also passed directly into a shell command, resulting in an avenue for command injection. The workflow was also triggered by an issue event, which was incorrectly referenced with github.event.pull_request.user.login as the event check reference.
In the absence of the referenced pull request property, this condition evaluated with an empty value, resulting in regular issues reaching the vulnerable job without any protection. The issue was not related to any released versions of the Snowflake Connector for .NET and affected the repository's CI/CD automation.
Using the Red Agent, Wiz researchers discovered the vulnerability on June 23 as part of a security research project conducted by Snowflake’s HackerOne vulnerability disclosure program. Five days prior, after pull request #1218 was merged, a security flaw had been introduced, and an unauthenticated user could activate it by using a specially crafted GitHub issue title.
The scan conducted by GitHub Advanced Security, which included Copilot Autofix, examined a revised version containing the vulnerable workflow, however, did not identify the injection. As a result of discovering the flaw, the Red Agent verified access to sensitive information within Snowflake’s internal Jira system.
Code that has been compromised originated in a cleanup-related pull request that replaced a safer environment-variable and jq parsing approach with direct interpolation of the title of an issue into a shell script, which is the source of the vulnerable code.
GitHub's security tooling flagged other issues during the development process and Copilot suggested fixes, but neither identified the injection caused by the change. Ultimately, a human reviewer approved and merged the pull request.
In June of 2026, when the workflow became active, any new issues could be accessed by the vulnerable code path.
Wiz’s Red Agent discovered the vulnerability five days later and successfully refined its exploit after an initial attempt to exploit it failed. As a result of the resulting payload, the researchers were able to access sensitive data within Snowflake’s internal Jira environment and obtain the Jira API token, enabling them to determine the potential impact of the vulnerability.
A number of questions are raised by the incident regarding automated security review and AI-assisted software development. Wiz pointed out that coding tools can inadvertently reintroduce unsafe shell practices, while security scanners fail to detect the injection that occurs. The case underscores the importance of thoroughly reviewing code changes involving GitHub Actions, particularly when workflows handle sensitive credentials or untrusted input.
Snowflake was informed of the vulnerability by Wiz through HackerOne on June 23, 2026, under report #3819931. Snowflake resolved the issue on June 24, 2026, by submitting pull request #1402, which replaced direct expansion of GitHub issue data with environment variables passed as arguments to jq. The Jira token was rotated on June 24.
The investigation conducted by Snowflake did not reveal any evidence of unauthorized access, and Wiz reported that no unrelated external use of the exposed token was observed during the five-day exposure period. There has been no release of the company's underlying audit logs. Furthermore, GitHub's commit history does not indicate that Copilot was the author of the changes to the jira_issue.yml file.
Despite the fact that Copilot Autofix appears to be a co-author of the squash merge, the unsafe refactoring was contained in a separate commit attributed to a Snowflake developer. Consequently, the available history confirms Copilot's participation in the pull request, but does not substantiate that the code was introduced by it.
This case demonstrates GitHub's warnings of workflow security risks in 2025, particularly when issue data is directly used in run blocks, which poses a security risk to workflows.
As of August 17, 2026, no CVE, CVSS score, or CISA KEV listing had been identified for this vulnerability. The vulnerable code has since been removed from the master branch, and there is no evidence that it has been exploited outside of the master branch.
