# Snowflake's Own Repo Had a GitHub Actions Flaw That Handed Over Jira Credentials


It's one thing to get breached through your customers' misconfigured cloud instances. It's another to leave the door open in your own public repository, where anyone with a GitHub account can knock.


Researchers at Wiz disclosed this week that Snowflake's snowflakedb/snowflake-connector-net repository — the official .NET connector maintained by Snowflake engineers — contained a GitHub Actions workflow injection vulnerability that could be triggered by nothing more elaborate than a crafted issue post. The vulnerable workflow, .github/workflows/jira_issue.yml, was designed to sync GitHub issues into Snowflake's internal Jira. The problem: it processed user-controlled input from issue titles or bodies and interpolated that content directly into shell commands, without sanitization. Classic injection, new surface.


## The Anatomy of a Weaponized GitHub Issue


Workflow injection in GitHub Actions isn't new — the security community has flagged the underlying patterns for years. But the mechanics are worth spelling out, because the attack surface is still chronically underappreciated.


When a GitHub Actions workflow triggers on events like issues or issue_comment, it has access to event context that contains user-supplied data: the issue title, the body, the commenter's username. If a workflow author pulls that data into a run: step via expression syntax — something like ${{ github.event.issue.title }} dropped into a shell command — an attacker who creates an issue with a title containing $(evil command) or backtick injection gets code execution inside the workflow runner.


That runner has access to whatever secrets are mounted in the job. In this case: Jira credentials. Depending on how those credentials are scoped, the blast radius ranges from reading internal ticket data (bug reports, security disclosures, vulnerability timelines) to writing into Jira, impersonating the service account, or pivoting to other systems that trust the same token.


The attack requires a GitHub account and the ability to open an issue — both trivially obtainable. Public repositories with issue creation enabled are, by design, open to the world.


## Context That Matters: This Is Snowflake


The timing here deserves attention. Snowflake spent much of 2024 at the center of one of the year's most damaging breach campaigns. Attackers — eventually attributed to the UNC5537 threat actor — accessed dozens of Snowflake customer environments using stolen credentials, no MFA required. The fallout included data from Ticketmaster, Santander, AT&T, and more than 160 other organizations. The company's public response emphasized that the compromises weren't the result of a Snowflake platform vulnerability, but rather customer credential hygiene failures.


That framing was defensible — technically. But it set a high standard. A company that spent months positioning itself as secure-by-design, whose customers were told to harden their own environments, maintaining an injectable workflow in a public repo is not a good look. It's exactly the kind of detail that erodes trust in the quiet way that a major breach announcement doesn't.


This isn't meant to pile on. Every large engineering organization has CI/CD hygiene debt. The point is that the pressure on Snowflake to demonstrate security credibility is real, and this is the opposite of that.


## Jira as an Intelligence Target


Most write-ups on workflow injection focus on the code execution angle. The credential theft angle — specifically Jira credentials — is worth taking seriously on its own terms.


Internal Jira instances for companies like Snowflake contain:

  • Bug and vulnerability trackers: including pre-disclosure security issues
  • Engineering roadmaps: what's being built, when, and by whom
  • Customer escalations: potentially including named accounts and their specific problems
  • On-call and incident data: recent outages, root causes, workarounds

    • An attacker who reads Snowflake's Jira doesn't need to exploit a Snowflake product vulnerability — they just need to find one that's already been found internally and is waiting for a patch. In the threat intelligence trade, that's called getting on the inside of the disclosure window.


    ## What Defenders Should Take From This


    The Snowflake/Wiz disclosure is a useful forcing function for security teams to audit their own GitHub Actions footprint, because most organizations have never done it systematically.


    The highest-risk patterns to look for:


  • ${{ github.event.issue.title }} or body in run: steps — this is the canonical injection pattern. Grep your workflows now.
  • pull_request_target with checkout of PR head — a related and well-documented footgun where workflows run in a privileged context but execute attacker-controlled code.
  • Workflows that mount production credentials — Jira tokens, cloud provider keys, NPM tokens — ask whether each workflow actually needs that access or whether it was added for convenience.
  • Issue and comment triggers on public repos — any on: [issues] or on: [issue_comment] workflow that processes event data should be treated as an untrusted input boundary.

    • The fix pattern is straightforward: never interpolate GitHub event context directly into shell commands. Use toJSON() to pass data safely, or intermediate environment variables that shell correctly escapes. GitHub's own documentation on [security hardening for GitHub Actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions) covers this — the problem is that developers don't read it before they write the workflow.


    ---


    ## HackWire Analysis


    This vulnerability fits a pattern that's been building for two years: CI/CD pipelines are the new network perimeter, and most organizations aren't treating them that way.


    The shift matters because the attack economics changed. Compromise a GitHub Actions workflow in a widely-used open-source repository and you've potentially poisoned every consumer of that package — that's supply chain leverage without the sophistication required to compromise a package registry. But even absent supply chain implications, workflow injection against internal repos gives attackers credential access that was previously only available through endpoint compromise or phishing.


    Snowflake's case also illustrates a specific failure mode: security investment gets concentrated where incidents happened, not necessarily where the next one will. After 2024's credential-theft campaign, Snowflake tightened customer-facing MFA requirements and authentication controls. But CI/CD pipeline security is an internal engineering hygiene problem — it lives in a different team, a different threat model, often a different conversation.


    The Wiz disclosure is responsible and specific, and Snowflake appears to have addressed the workflow. But the broader question is how many jira_issue.yml equivalents exist across the industry — automation workflows built by engineers who weren't thinking about security, processing untrusted input, holding credentials nobody audits. The answer, based on public research scanning GitHub Actions workflows at scale, is: a lot.


    For security teams at companies with significant GitHub footprints: this is a table-stakes audit item. Run a grep across your workflow files for event context interpolation today. The fix is a day of engineering time. The alternative is explaining to your CISO how a GitHub issue became an incident.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)