Researchers at Wiz identified a workflow injection vulnerability in the public GitHub repository snowflakedb/snowflake-connector-net, which allowed an attacker to execute arbitrary commands in the GitHub Actions runner environment simply by creating a specially crafted Issue. During authorized testing, the researchers extracted a Jira API token that, according to them, provided read access to Snowflake’s internal projects, including engineering tasks, security compliance tracking, and bug bounty. The vulnerability existed in the repository’s CI/CD automation for five days — from June 18 to 23, 2026 — and was fixed on the same day the report was received. No affected releases of the .NET connector were identified.
Vulnerability mechanism
The issue was located in the file .github/workflows/jira_issue.yml, which was triggered when a public Issue was opened in the repository. The workflow contained two critical flaws:
- Direct interpolation of user input in a shell block: the Issue title and body were inserted directly into the
run:block, creating a classic command injection vector. An attacker could inject arbitrary shell commands via the Issue text. - Non-functional authorization check: the workflow checked the value of
github.event.pull_request.user.login, even though the event trigger was an Issue, not a Pull Request. According to the GitHub documentation, accessing a non-existent context property returns an empty string. As a result, the comparison withwhitesource-for-github-com[bot]never worked as a filter, and any user could trigger the workflow.
In the same workflow step, the secrets JIRA_BASE_URL, JIRA_USER_EMAIL and JIRA_API_TOKEN were available, which meant that a successful command injection automatically granted access to these credentials.
Exploitation and impact scope
According to Wiz, their automated system Red Agent discovered and exploited the vulnerability during authorized security testing. The initial payload caused a shell syntax error, after which the system adapted its approach. The researchers report that they received an out-of-band callback from the GitHub Actions runner and extracted the Jira API token.
According to the Wiz report, the token belonged to the account [email protected] and provided read access to Jira projects on the domain snowflakecomputing.atlassian.net, covering engineering tasks, security compliance tracking, and bug bounty. It should be noted that the exploitation details and the scope of the obtained privileges are based solely on Wiz’s statements — Snowflake’s public audit logs have not been disclosed.
Timeline and remediation
- June 18, 2026 — the vulnerable workflow was merged into the main branch via pull request #1218 (squash merge, commit
4a1b8ce). - June 23, 2026 — Wiz submitted a report via HackerOne (report #3819931). On the same day, Snowflake applied a fix in pull request #1402, replacing direct interpolation of GitHub expressions with passing values through environment variables into
jq. - June 24, 2026 — according to Wiz, the Jira token was rotated.
In a statement reproduced by Wiz, Snowflake said that the investigation “did not identify evidence of unauthorized access.” According to Wiz, Snowflake’s review did not find any third-party use of the token during the five-day exposure window. However, Snowflake’s audit logs were not published, and independent verification of these claims is not possible.
Attribution question: the role of GitHub Copilot
Wiz described the vulnerability as the result of a change made by GitHub Copilot Autofix. However, an analysis of the repository’s commit history paints a more complex picture. Commit 6d0e2fa, explicitly marked as co-authored by Copilot Autofix, modified the jira_close.yml file, not the vulnerable jira_issue.yml. The unsafe refactoring of jira_issue.yml is contained in a separate commit 094038e, attributed on GitHub to developer sfc-gh-hpathak. Both changes were included in the final squash merge 4a1b8ce, where Copilot Autofix is listed among the co-authors. Thus, Copilot’s involvement in the pull request is confirmed, but authorship of the specific vulnerable lines of code is not.
Systemic issue and recommendations
This incident is a typical example of a class of vulnerabilities documented by GitHub back in July 2025: direct interpolation of untrusted data from events (Issue title, body, comments) into run: blocks in GitHub Actions. The recommended approach is to use intermediate environment variables, which is exactly what Snowflake implemented in its fix.
Organizations using GitHub Actions in public repositories should:
- Audit all workflow files for direct interpolation of
${{ github.event.* }}expressions insiderun:blocks. Any data from Issues, Pull Requests, or comments should be passed via environment variables. - Verify filtering conditions in workflows: ensure that authorization checks reference properties that exist in the context of the actual trigger event. A mismatch between event type and checked property leads to filter bypass.
- Minimize the scope of secrets: do not pass credentials into steps that process user input. Separate input validation steps from steps that use secrets.
- Implement automated scanning of workflow files — for example, using tools like
actionlint— to detect unsafe interpolation patterns at the code review stage.
This case demonstrates that even in the absence of a vulnerability in the product itself, compromising the CI/CD infrastructure of a public repository can lead to the leakage of internal credentials with access to corporate systems. The five-day exposure window and prompt fix on the day of the report are a positive example of response, but the very fact that unsafe code reached the main branch indicates a need to strengthen security checks for workflows at the merge stage. Organizations with public repositories on GitHub should promptly review their Actions configurations for similar patterns of directly substituting data from events.
