What happened
Researchers at Wiz disclosed a GitHub Actions workflow injection in Snowflake's public snowflakedb/snowflake-connector-net repository. The vulnerable workflow, jira_issue.yml, ran whenever anyone opened an issue on the repository, and it exposed internal Jira credentials to the same job. Because the workflow inserted the attacker-controlled issue title and body directly into a shell command, a crafted issue could execute arbitrary commands in the runner.
Wiz's Red Agent system exploited the flaw during authorized testing, received an out-of-band callback from the runner, and retrieved the Jira API token used by the workflow. The token belonged to qa@snowflake.net and allowed read access to Jira projects covering engineering, security compliance, and bug bounty tracking. The researchers reported the issue through HackerOne on June 23, and Snowflake merged a fix the same day, replacing direct expression expansion with environment variables passed to jq as arguments.
Snowflake said its investigation found no evidence of unauthorized access. The Jira token was rotated on June 24, and Snowflake's review found no unrelated external use during the exposure window. As of August 17, no CVE, CVSS score, or CISA Known Exploited Vulnerabilities catalog entry had been published for the issue, and Snowflake's underlying audit logs have not been made public.
Why this is a GRC story
This looks like a developer story, but it is really a governance story. CI/CD pipelines now hold the same kind of secrets that used to live only in production systems. A workflow that triggers on public input, any public input, is an attack surface, and when that workflow carries credentials with read access to security and bug bounty projects, the blast radius is measurable.
The second angle is that this class of flaw was documented. GitHub warned about expanding untrusted issue data inside run blocks back in July 2025 and recommended intermediate environment variables. The unsafe pattern still shipped, which is a reminder that documented guidance only helps if it becomes part of a review checklist.
The third angle is assurance. Snowflake states there was no unauthorized access, and that may be exactly right, but without published audit logs the claim is hard for outsiders to verify. For anyone doing vendor due diligence, that gap matters.
What to watch
Treat your own pipelines as in-scope assets. Inventory which workflows consume untrusted input, confirm secrets are scoped to least privilege, and make sure rotation and audit trails exist before an incident, not after. If you review third-party tools and repos, ask whether their automation follows the same discipline. The fix here was quick, which is the part Snowflake got right. The lesson for everyone else is to never need the fix at all.
Attribution: Analysis based on The Hacker News reporting and related public disclosures. This article is original commentary, not a repost of the source material.