DEV Community

Hamza
Hamza

Posted on Originally published at tekmag.thsite.top

Snowflake GitHub Actions Flaw Lets Crafted Issues Trigger Command Injection

#snowflake #githubactions #wiz #aisecurity

Originally published at https://tekmag.thsite.top/snowflake-github-actions-flaw-lets-crafted-issues-trigger-command-injection/

Snowflake GitHub Actions injection

Snowflake has patched a GitHub Actions workflow injection vulnerability in its public connector repository that allowed an unauthenticated user to execute arbitrary commands by opening a crafted issue. The flaw, introduced five days before discovery by a GitHub Copilot Autofix change, granted the attacker read access to Snowflake's internal Jira projects. Wiz researchers found and exploited the bug through the company's HackerOne program; Snowflake confirmed no unauthorized access occurred.

A Security researcher at Wiz recently found a code injection vulnerability in a public Github repository belonging to Snowflake, the cloud data platform. The vulnerability let anyone with a GitHub account trigger command execution on Snowflake's CI/CD servers by simply opening an issue with a malicious title.

The flawed Workflow file sat in .github/workflows/jira_issue.yml inside the snowflakedb/snowflake-connector-net repository, which hosts the company's official .NET connector. The workflow ran every time a public issue was opened, pulling the issue title into a shell script block and passing it to a command that queried an internal Jira instance. The problem was that the issue title was interpolated directly into the script without sanitization.

The vulnerability existed for roughly five days between June 18 and June 23, 2026. It was fixed after Wiz reported it through Snowflake's HackerOne bug bounty program. The company stated its investigation found no evidence that anyone other than the researchers accessed the system during that window.

Key Takeaways

  • A GitHub Copilot Autofix commit removed a safe input-sanitization pattern and replaced it with direct shell interpolation, creating a command injection vector.
  • The vulnerability lived in Snowflake's CI/CD automation, not in any released connector product.
  • Wiz's autonomous Red Agent discovered the flaw, adapted its exploit after an initial syntax error, and confirmed access to internal Jira credentials.
  • Snowflake patched the workflow and rotated the affected Jira token within 48 hours of disclosure.
  • No CVE or CVSS score has been assigned, and no evidence of unauthorized access was found.

How the vulnerability worked

The workflow jira_issue.yml was triggered by the issues: opened event on GitHub. When an issue was opened, the workflow grabbed the issue title and passed it into a run: block as a shell variable:

run: |
  TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\\'/g")
  curl ... --data-urlencode "title=${TITLE}" ...

The sed escaping ran after GitHub's template expansion. A single quote in the issue title closed the echo '...' string and let an attacker inject arbitrary shell commands. The workflow also contained a guard condition that checked whether the author matched a specific bot account, but on an issues event the pull_request property is null, so that check always evaluated to true and provided no protection.

Wiz's Red Agent sent a crafted issue containing a payload that exfiltrated the Jira API token stored as an environment variable in the workflow. The agent received an out-of-band callback from a GitHub Actions runner hosted on Azure, confirming the command had executed.

What went wrong

The vulnerable code arrived in a squash commit dated June 18, 2026, attached to pull request #1218. That commit lists "Copilot Autofix powered by AI" as a co-author. According to Wiz, the AI assistant removed a previously safe pattern that passed the issue title through an environment variable and constructed the JSON payload with jq, replacing it with the direct interpolation shown above.

The original safe pattern looked like this:

env:
  ISSUE_TITLE: ${{ github.event.issue.title }}
run: jq -n --arg title "$ISSUE_TITLE" ...

The jq approach treats the input as data, not as executable code, and does not allow shell breakout. The change that introduced the vulnerability collapsed that guard into a bare string expansion inside a run: block. GitHub has documented this class of workflow injection since July 2025, advising developers to route untrusted input through environment variables rather than interpolating it directly into shell scripts.

What the researchers accessed

The exfiltrated token authenticated as qa@snowflake.net against Snowflake's internal Jira instance at snowflakecomputing.atlassian.net. Wiz confirmed it could read projects covering engineering work, security compliance tracking, and bug bounty administration. The token was revoked and rotated the day after disclosure, on June 24, 2026.

The vulnerability was limited to the repository's CI/CD workflow. No Snowflake Connector for .NET release was affected, and the interpolation flaw does not exist in released software. The underlying Jira permissions, workflow run logs, and audit records were not made public.

The timeline

  • June 18, 2026 — Commit 4a1b8ce lands on the default branch. It removes the safe env: + jq pattern and introduces direct shell interpolation in jira_issue.yml. The commit is part of PR #1218 and lists Copilot Autofix among its co-authors.
  • June 23, 2026 — Wiz identifies the vulnerability through its HackerOne program, exploits it to confirm credential access, and files report #3819931.
  • June 23, 2026 — Snowflake merges the fix in PR #1402 (commit 1dc7766), restoring the env: + jq pattern.
  • June 24, 2026 — The affected Jira token is rotated.

Snowflake's disclosure policy sets a 30-day window after resolution, making July 25, 2026, the target date for public release of the full advisory.

What Snowflake said

In a statement provided to Wiz, Snowflake said:

"Snowflake appreciates Wiz's responsible reporting of and collaboration around these findings through our vulnerability disclosure and bug bounty program, HackerOne. ... our investigation found no evidence of unauthorized access."

The company added that it is working with Wiz to share the learnings with the broader industry. Wiz confirmed that all data accessed during proof-of-concept testing was deleted and that its autonomous agent adapted its exploit mid-attempt when the first payload triggered a bash syntax error.

Why this matters

This incident illustrates a specific risk pattern that is becoming more common as AI coding assistants enter mainstream development workflows. The tool that introduced the vulnerability did not set out to create a security hole. It replaced a verbose but safe pattern with a shorter one that happened to be insecure. AI coding assistants predict code based on probabilistic patterns in existing repositories. When they remove a sanitization step in favor of a more concise form, they can strip away the very safeguard that was put in place for a reason.

The five-day exposure window also shows how fast autonomous security agents can close the loop. Wiz's Red Agent scanned Snowflake's public GitHub organization, identified the vulnerable workflow, crafted an exploit, adjusted its approach when the first attempt failed, and confirmed access — all without human intervention. Security teams operating in an environment where flaws are discovered in days rather than months need to treat AI-assisted code changes with the same scrutiny as any other pull request.

What to do next

Developers using GitHub Actions should audit any workflow that interpolates user-controlled input — issue titles, PR descriptions, comment text — directly into a run: block. Pass that input through an env: variable and use a parser such as jq or python -c to construct command arguments, rather than relying on string escaping inside shell scripts. Teams relying on AI-assisted code generation should treat autofix suggestions as they would any patch from an external contributor: verify that the change does not remove input validation, and run static analysis before merging.

Frequently Asked Questions

Q1: Was Snowflake's public data exposed?
No. The vulnerability was confined to a CI/CD workflow file in a public repository. It did not affect any released Snowflake Connector for .NET product, and no customer data was involved.

Q2: What data did the researchers access?
The exfiltrated Jira API token granted read access to Snowflake's internal Jira projects, including engineering, security compliance, and bug bounty tracking. The token was rotated within 24 hours of disclosure.

Q3: Was the vulnerability caused by GitHub Copilot?
The unsafe code landed in a commit co-authored by "Copilot Autofix powered by AI," but the commit history does not establish Copilot as the sole author of the vulnerable lines. The change removed an existing safe pattern and replaced it with direct shell interpolation, which the AI assistant generated as part of a larger pull request.

Q4: Has a CVE been assigned?
As of August 17, 2026, no CVE, CVSS score, or CISA Known Exploited Vulnerabilities entry had been publicly assigned to this issue.

Q5: Is there evidence of malicious exploitation?
Snowflake stated that its investigation found no evidence of unauthorized access during the five-day exposure window. All anomalous queries matched to Wiz's testing IPs.

Conclusion

This article has examined the key developments, regulatory dynamics, and market implications of this topic. As the situation continues to evolve, stakeholders should monitor upcoming milestones and assess how these changes align with their strategic priorities.

References

Top comments (0)