Snowflake GitHub Actions Injection Exposed Jira Secrets via Crafted Issues

As reported by The Hacker News, security researchers at Wiz disclosed a GitHub Actions workflow injection vulnerability in Snowflake's public snowflakedb/snowflake-connector-net repository. The flaw, present in .github/workflows/jira_issue.yml, allowed an attacker to execute arbitrary commands on a GitHub Actions runner and exfiltrate internal Jira API credentials by opening a crafted GitHub issue. The vulnerability existed for only five days before remediation, and Snowflake reports no evidence of unauthorized access beyond the authorized red team test.

Vulnerability Summary

Why This Matters Beyond Snowflake

This incident is less about Snowflake's specific misstep and more about a systemic blind spot in CI/CD security. The vulnerable workflow expanded github.event.issue.title and github.event.issue.body directly into a shell run: block — a pattern that remains depressingly common across open-source and enterprise repositories alike. Any public repository with a workflow that triggers on issues or issue_comment events and interpolates user-controlled fields into shell commands is equally exploitable.

The secondary failure — checking github.event.pull_request.user.login inside an issue-triggered workflow — is a subtler but equally important lesson. GitHub's expression language silently returns empty strings for nonexistent properties rather than failing. This design choice turned an intended authorization check into a no-op, allowing any public issue to reach the vulnerable job. Defenders should audit their workflows for property dereferences that assume event types different from what actually triggers the job.

The five-day exposure window from merge to fix is a reminder that secrets in CI/CD pipelines are only as safe as the most recent commit. Token rotation after disclosure is necessary but insufficient — organizations need pre-merge static analysis of workflow files to catch injection patterns before they reach the default branch.

Who Is at Risk

• Open-source maintainers with public repositories using issue-triggered workflows that interact with external APIs (Jira, Slack, project management tools)
• Enterprise engineering teams with automated issue-to-ticket pipelines that pass user content into shell scripts or API calls
• Organizations using AI-assisted code generation tools — Wiz noted a potential GitHub Copilot Autofix connection, raising questions about whether automated remedication tools can introduce vulnerable patterns

Shield53 Recommendations

Immediate Actions:

• Audit all GitHub Actions workflows across your organization for issues, issue_comment, and pull_request triggers that expand event data into shell run: blocks. Search for patterns like ${{ github.event.issue.* }} or ${{ github.event.pull_request.* }} in run: contexts.
• Replace direct GitHub expression expansion in shell commands with environment variable injection using the env: keyword, then reference variables as $VARIABLE inside the script. This is the pattern Snowflake adopted in its fix.
• Implement pre-merge workflow validation using tools like actionlint or GitHub's own workflow syntax checks. Add custom rules to flag user-controlled event properties in run: blocks.
• Verify that event-type guards in workflows actually match the trigger event. Use github.event_name checks rather than dereferencing properties that may not exist for the current event.
• Rotate any secrets that were present in workflows during the exposure window and review Jira, Slack, or API audit logs for anomalous access patterns.

Longer-Term Hardening:

• Adopt OIDC-based short-lived credentials for CI/CD workflows instead of long-lived API tokens stored as repository secrets. This limits blast radius if a workflow is compromised.
• Scope all CI/CD secrets to the minimum permissions required. The Jira token in this case had read access across engineering, security compliance, and bug bounty projects — broader than necessary for creating issue tickets.
• Enable GitHub's secret scanning and push protection to catch credentials before they enter repository history.
• Consider restricting which workflows can access specific secrets using environment-level secret scoping rather than repository-level secrets.

The Snowflake incident underscores that CI/CD pipelines are production-adjacent infrastructure. A crafted GitHub issue is now a viable initial access vector. Organizations that treat workflow files as low-risk configuration rather than executable code with secret access are operating with a false sense of security.