The Jira API token exposed by a flawed GitHub Actions workflow in Snowflake's public snowflakedb/snowflake-connector-net repository belonged to qa@snowflake.net, according to Wiz.
The vulnerability in .github/workflows/jira_issue.yml
Researchers at Wiz disclosed a GitHub Actions workflow injection vulnerability in the repository's .github/workflows/jira_issue.yml that ran when a public issue was opened. The workflow exposed three environment values — JIRA_BASE_URL, JIRA_USER_EMAIL, and JIRA_API_TOKEN — to the same workflow step, and it inserted attacker-controlled issue title and body values directly into a shell run: block. Wiz said this combination could be exploited through a crafted GitHub issue to execute commands in a workflow containing internal Jira credentials.
How the workflow logic failed and why GitHub's behavior mattered
The jira_issue.yml step also checked github.event.pull_request.user.login even though the triggering event was an issue; the referenced pull_request property did not exist. As GitHub explained, "If you attempt to dereference a nonexistent property, it will evaluate to an empty string." In this case, the attempted comparison against whitesource-for-github-com[bot] did not prevent an ordinary issue from reaching the vulnerable job, allowing untrusted issue data to be expanded inside the run: block.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildWiz's authorized test: Red Agent, a shell error, and a live callback
Wiz reported that its Red Agent system exploited the injection during authorized security testing. The first payload produced a shell syntax error, prompting the researchers to change their approach; subsequent activity produced an out-of-band callback from the GitHub Actions runner and enabled them to obtain the Jira API token used by the workflow. Wiz said the token allowed read access to Jira projects covering engineering, security compliance, and bug bounty tracking on snowflakecomputing.atlassian.net, but that underlying Jira permissions, the workflow run, and audit records have not been made public.
Timeline, remediation, and audit claims
Wiz filed the report with Snowflake through HackerOne on June 23, 2026 (report #3819931). Snowflake merged a fix the same day in pull request #1402; the change replaced direct GitHub expression expansion with environment variables that are passed to jq as arguments. The vulnerable workflow had reached the repository's default branch five days earlier, on June 18, when pull request #1218 was merged. Wiz said the Jira token was rotated on June 24 and that Snowflake's review found no unrelated external use of it during the five-day exposure window. Snowflake, quoted by Wiz, stated "our investigation found no evidence of unauthorized access." The corrected handling remains in the repository's master branch and the vulnerable interpolation is no longer present on master.
Repository history, Copilot Autofix, and public guidance
Wiz described the flaw as resulting from a GitHub Copilot Autofix change, but the repository history does not establish Copilot as the line-by-line author of the vulnerable jira_issue.yml code. The explicit Copilot co-authored commit 6d0e2fa changed jira_close.yml, while an unsafe jira_issue.yml refactor appears in an August 25, 2025 commit, 094038e, attributed to sfc-gh-hpathak. Both changes were folded into the June 18 squash merge commit 4a1b8ce, which lists Copilot Autofix among its co-authors; that history therefore confirms Copilot participation in pull request #1218 but does not prove authorship of the vulnerable lines. GitHub had previously documented this class of workflow injection in July 2025, warning against expanding untrusted issue data directly inside run: blocks and recommending the use of intermediate environment variables.
What this means for security teams, open-source maintainers, and enterprises
- Security teams: Review CI/CD workflows that accept public inputs — especially run: blocks that interpolate event data — and validate that repository credentials are not exposed to steps that handle untrusted values. The fix applied by Snowflake — replacing direct expression expansion with environment variables passed to jq — is an explicit countermeasure cited in the report.
- Open-source maintainers: Check historical pull request merges and co-author attributions carefully when diagnosing how insecure changes reached protected branches; the repository history here shows multiple commits and a squash merge that folded changes together, complicating simple attribution.
- Enterprises and procurement leaders: Note that the exposed Jira API token belonged to qa@snowflake.net and granted read access to multiple internal project areas; tokens and service accounts used in public CI workflows deserve strict audit, rotation, and least-privilege controls.
As of August 17, 2026, no CVE, CVSS score, or CISA Known Exploited Vulnerabilities (KEV) catalog entry had been located for the issue, and Wiz's primary material does not establish malicious exploitation in the wild or customer compromise. The record in this case documents a short window of exposure, an authorized offensive test that retrieved a live token, an immediate fix and rotation, and an audit claim of no evidence of unauthorized access — but the underlying Jira audit logs and workflow run records remain private.
