A booby-trapped GitHub ticket could have stolen Snowflake's internal Jira keys

Key points

• Wiz researchers found a command-injection flaw in Snowflake's public snowflake-connector-net repository on GitHub, disclosed in November 2025.
• The buggy file, .github/workflows/jira_issue.yml, ran automatically whenever anyone opened an issue on the project.
• A specially written issue title could trick the workflow into running attacker commands with access to Snowflake's internal Jira login secrets.
• Snowflake has fixed the workflow; there is no public evidence the flaw was abused before the patch.
• The bug is a textbook GitHub Actions injection, a class of mistake GitHub itself has warned about since 2020.

Security researchers at Wiz have found a flaw in one of Snowflake's public code projects that could have handed strangers the keys to the company's private issue tracker.

Snowflake is the big cloud data-warehouse company. The project in question, snowflake-connector-net, is open-source code that lets .NET applications talk to Snowflake. It lives on GitHub, the site where most of the world's software is developed in public.

The problem sat in an automation script that ran every time somebody opened a new issue, meaning a bug report or feature request, on that project. That script's job was to copy the issue into Snowflake's internal Jira, the private ticket system the company's engineers use day to day.

To do that, the script had to log in to Jira. So it carried Snowflake's Jira credentials with it every time it ran.

How did the attack work?

An attacker only had to open a GitHub issue with a carefully crafted title. The automation script pasted that title straight into a shell command without cleaning it first, so anything the attacker wrote was treated as an instruction to the server, not as text.

This is called a workflow injection. It is the software equivalent of a form that asks for your name and then does whatever you type, including "delete everything".

Once the attacker's commands were running inside Snowflake's automation, they could read the Jira credentials the script was already holding, then send them anywhere on the internet.

The faulty file was .github/workflows/jira_issue.yml, first reported by The Hacker News based on Wiz's writeup. GitHub Actions is the built-in automation system GitHub offers, and workflow injection through issue titles, pull request bodies and branch names has been a known pitfall since GitHub published guidance on it in 2020.

What could an attacker have done with the Jira credentials?

Read and write access to Snowflake's internal Jira would be a serious prize. Jira tickets often contain unfixed security bug reports, customer names, internal architecture notes and screenshots that were never meant to leave the company.

An attacker with those credentials could quietly read tickets, watch for the next unpatched flaw, or file convincing fake tickets to trick Snowflake staff.

There is no indication in Wiz's disclosure that any of this happened. Snowflake fixed the workflow after being told.

Does this affect Snowflake customers?

Probably not directly. The bug was in Snowflake's own build automation, not in the data warehouse product that customers log into. Customer data stored in Snowflake was not touched by this flaw.

The wider lesson lands on every company that runs GitHub Actions: any workflow that fires on public events, like a new issue or a pull request, must treat every piece of user text as hostile.

The pattern to watch

On the identity side, this is really a secrets-management story dressed up as a code bug. The workflow held a long-lived Jira credential, and one shell-injection was enough to leak it. Short-lived tokens via OpenID Connect federation, described in GitHub's own Actions documentation, would have limited the blast radius. Multi-factor authentication would not have helped here, honestly, because the credential was a machine secret, not a human login.