Snowflake GitHub Actions Flaw: How a Public Issue Exposed a Jira API Token

The Snowflake GitHub Actions flaw shows how a public GitHub issue can become a path into an internal enterprise system. In Snowflake’s snowflakedb/snowflake-connector-net repository, attacker-controlled issue data reached a GitHub Actions shell step that also held credentials for an internal Jira integration.

Wiz disclosed the flaw after Red Agent exploited the workflow injection during authorized testing. A crafted issue title enabled command execution and exposed a Jira API token. Snowflake patched the workflow on June 23, 2026, rotated the credential the next day, and reported no evidence of unauthorized access.

The incident did not expose a vulnerability in a released Snowflake Connector for .NET package. It showed how a small change in automation can connect public, untrusted input to privileged CI/CD credentials.

Five days turned a workflow change into an exposed trust boundary

The vulnerable workflow reached Snowflake’s default branch when PR #1218 was merged on June 18, 2026. Wiz discovered and reported the issue five days later.

Key points:

• The earlier workflow handled the GitHub issue title through an environment variable and passed it to jq as structured data.
• The merged version inserted ${{ github.event.issue.title }} directly into a shell run: block.
• GitHub resolves that expression before the shell executes, so attacker-controlled issue content could alter the generated script.
• The attempted sed sanitization happened after interpolation, which meant it could not reliably prevent command injection.
• The Snowflake GitHub Actions flaw shows why public issue data should never flow directly into executable shell syntax.

GitHub warns that values such as issue titles, pull request bodies, branch names, and labels can contain untrusted input. Workflows should keep those values as data rather than place them directly inside shell commands.

A GitHub issue became executable input

The affected jira_issue.yml workflow ran when a new issue was opened, giving public users a path to trigger the automation.

• The workflow placed ${{ github.event.issue.title }} directly inside a shell run: block.
• A crafted title could break out of the intended string and inject additional shell commands.
• Wiz’s Red Agent demonstrated the flaw during authorized testing and adjusted its payload after an initial syntax error.
• The successful payload exposed Jira credentials available to the workflow, including the API token.
• This GitHub Actions command injection turned untrusted issue content into executable input inside a privileged CI/CD context.

The core failure was not the existence of user-controlled data, but allowing that data to cross directly into shell syntax before execution.

The Jira API token made command execution consequential

Command execution became more serious because the affected workflow step also had access to internal Jira credentials.

• The step exposed JIRA_BASE_URL, JIRA_USER_EMAIL, and JIRA_API_TOKEN as environment variables.
• Wiz reported extracting those credentials during its authorized test.
• The Jira API token authenticated as qa@snowflake.net.
• According to Wiz, it provided read access to Jira projects involving engineering, security compliance, and bug bounty tracking.
• Snowflake later rotated the credential and reported no evidence of unauthorized access beyond the authorized research.

The incident shows how CI/CD secret exposure can expand a workflow injection issue beyond the runner itself. When automation carries credentials for connected services, successful command execution can expose those downstream trust relationships too.

A guard condition existed, but it did not establish trust

The workflow contained an if: expression that referenced github.event.pull_request.user.login.

Because the workflow ran on an issues event, github.event.pull_request was not populated. The resulting comparison still evaluated as unequal to the specified bot account, allowing ordinary issue submitters to pass the condition.

The Snowflake GitHub Actions flaw highlights a broader DevSecOps security problem: authorization logic can look correct in isolation while behaving differently under the event that actually triggers the workflow.

Teams should test workflow conditions against every configured event, not review if: expressions only for syntax and intent.

AI involvement is notable, but attribution needs precision

The June 18 squash commit credits Copilot Autofix powered by AI as a co-author, while Wiz reported that GitHub’s AI-assisted security review did not flag the vulnerability. Public evidence does not conclusively establish that Copilot authored the vulnerable jira_issue.yml lines.

For DevSecOps security, the lesson is straightforward: AI-assisted changes need the same scrutiny as human-written code.

• Review AI-assisted workflow changes for security regressions.
• Compare sensitive changes against the previous implementation.
• Require human review for .github/workflows/ modifications.
• Use workflow-aware security linting before merge.

AI can accelerate development and review, but it does not reduce the security requirements of the resulting code.

CI/CD secrets need smaller blast radii

The Snowflake incident shows why workflow security must include limiting what an exploited job can access.

• Give service tokens only the permissions required.
• Expose secrets only to the jobs or steps that need them.
• Separate public-input processing from privileged automation.
• Rotate potentially exposed credentials and review downstream service audit logs.

These controls reduce CI/CD secret exposure and support broader software supply chain security by limiting how far a compromised workflow can reach beyond the CI/CD environment.

Featured resource

Cybersecurity kit

Download the free cybersecurity kit: blueprints, frameworks, checklists, templates, and guides to secure your enterprise today.

DOWNLOAD

Where Hexnode fits into the defensive boundary

This incident sits primarily in the GitHub workflow, repository, and secret-management layer. Hexnode does not replace those controls.

Hexnode UEM and Microsoft Entra Conditional Access

Hexnode UEM can report device compliance status to Microsoft Entra ID, allowing Conditional Access policies to use that status when evaluating access to configured organizational resources.

• Device compliance: Define compliance requirements for managed devices.
• Access enforcement: Use compliance status in Microsoft Entra Conditional Access decisions.
• Endpoint governance: Apply security policies and configurations to managed devices

Hexnode XDR

If an incident reaches managed Windows endpoints, Hexnode XDR can support endpoint investigation and containment.

• Endpoint isolation: Disconnect an affected endpoint from network communication.
• Process termination: Stop malicious processes or process trees.
• File quarantine: Isolate malicious files from the operating system and user.

These capabilities support endpoint-layer defense, while GitHub workflow hardening, repository controls, secret management, and Jira token security remain outside Hexnode’s scope.

The Snowflake GitHub Actions flaw is a trust-boundary lesson

The Snowflake GitHub Actions flaw demonstrates how public input can reach internal credentials when CI/CD automation combines them within the same execution context.

The strongest defenses are architectural: keep untrusted values out of executable shell syntax, minimize the privileges available to public-triggered workflows, and treat workflow files as security-sensitive code. If those boundaries fail, least-privilege credentials and reliable audit logs can help limit and assess the resulting exposure.