Snowflake's Jira Token: A Flaw Copilot Co-Signed, and the Human GitHub Says Wrote It

On 23 June 2026 Red Agent, an autonomous security agent built by Wiz, opened an issue on a public GitHub repository owned by Snowflake and came back with a credential. The repository was snowflakedb/snowflake-connector-net, and the workflow at fault, .github/workflows/jira_issue.yml, exists to file a Jira ticket whenever anybody opens an issue — it built the ticket title into a shell command instead of passing it through an environment variable, so a crafted title executed as code on the GitHub Actions runner. The token Red Agent recovered authenticated as qa@snowflake.net against snowflakecomputing.atlassian.net and carried read access to Snowflake's engineering, security-compliance and bug-bounty Jira projects. The flaw had been live for five days. Wiz published its full analysis on 17 August 2026. This incident is catalogued as record 2026-08-17-snowflake-jira-zhao-dao-can in the Orca AI Incident Archive, which holds the full record set with its confidence grades and cited sources.

The interpolation, and the guard that never ran

The workflow was triggered on the GitHub event "issues: opened". Anyone with a GitHub account could fire it by opening an issue on a public repository — no invitation, no maintainer role, no fork. The vulnerable step read the issue title into a shell variable: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...), with two filters that were meant to escape double quotes and single quotes before the string was assembled.

The failure is in the order of operations, not in the escaping. GitHub substitutes the contents of the expression into the script text before bash ever parses it, so a single quote inside the issue title closes the quoted string that echo is holding open. The two sed filters run inside that same script, after the substitution, and cannot repair quoting that has already changed how the line is parsed. Wiz's write-up is explicit that the escaping comes too late to prevent the breakout, and that a title crafted with a closing quote and a semicolon appends commands of the attacker's choosing to the run step.

A second control was supposed to narrow the audience and did not. The job carried an if condition comparing github.event.pull_request.user.login against the login of the whitesource-for-github-com bot, evidently to stop automated dependency pull requests from filing tickets. On an issues event there is no pull request object at all, so the comparison is against a null property. GitHub's own documentation, quoted by The Hacker News, states that dereferencing a nonexistent property evaluates to an empty string; Wiz's analysis reaches the same result through the null value. Either way the condition evaluated true for every user, and the exception for the bot became a pass-through for the internet.

What made the injection worth reporting rather than routine is the company it kept. The same step held JIRA_BASE_URL, JIRA_USER_EMAIL and JIRA_API_TOKEN as environment variables, so arbitrary command execution on the runner had a credential within reach rather than a blank substrate. No Snowflake Connector for .NET release was identified as affected: the weakness lived in the repository's CI/CD automation, not in shipped connector code.

What Red Agent took, and what it says it threw away

Wiz's account of the exploitation is the part that separates this from a scanner finding. The first payload used a hash character, which commented out the closing parenthesis of the TITLE=$(...) assignment and produced a bash syntax error instead of a callback. The agent read the error and rewrote the payload to close the shell block with a semicolon and a fresh echo quote, then received an out-of-band call. The payload used curl to reach a subdomain of oast.me with base64-encoded values of the three credential variables, and the callback arrived from Azure IP 20.106.182.197, an address Wiz attributes to a GitHub Actions runner.

The token it returned was a Jira API token for qa@snowflake.net, and Wiz describes its reach as read access spanning engineering, security-compliance and bug-bounty tracking projects on Snowflake's Atlassian cloud instance. That is the harm the archive records: not code execution on a build machine for five days, but a credential that could read the ticket queues where unfixed engineering and security bugs are filed — including, by Wiz's description, the bug-bounty tracker.

Wiz says it securely deleted everything it accessed during the proof of concept. Snowflake, in a statement to CSO Online, said the report "was immediately investigated and remediated" and that "our investigation found no evidence of unauthorized access"; Wiz's blog adds that Snowflake reviewed audit logs for the five-day window and found no third-party use beyond Wiz's own testing addresses. Snowflake has not published those logs, so the no-other-actor finding rests on its account and on Wiz's summary of it rather than on documents anyone outside the two organisations can read.

Who wrote the vulnerable line

That question produced the second, larger story. PR #1218, titled "SNOW-2069227: Update jira workflows", was squash-merged on 18 June 2026 as commit 4a1b8ce, and the squash commit lists Copilot Autofix powered by AI among its co-authors. Wiz's original headline leaned on exactly that, describing the flaw as sitting in a GitHub Copilot-assisted pull request, and early trade coverage followed the same line — SC Media's headline read "Wiz agent finds Snowflake repo flaw in code co-authored by GitHub Copilot Autofix".

GitHub's position, reported by The Next Web and summarised in a Cloud Security Alliance research note, is that its internal review found "a human wrote the contributions that led to the vulnerability" and that Copilot Autofix "neither reviewed nor contributed to them". The technical basis for that rebuttal is in the git history. Squash-merging collapses a pull request into a single commit and carries every co-author trailer forward regardless of which lines that author touched, so a co-author line records participation in the pull request, not authorship of a particular hunk. Copilot's co-authored commit in the same pull request, 6d0e2fa, changed jira_close.yml — a different workflow from the vulnerable jira_issue.yml. The unsafe interpolation is attributed to commit 094038e, dated 25 August 2025 and attributed by GitHub to a Snowflake engineer, sfc-gh-hpathak; PR #1218 put that pattern onto the default branch in June 2026.

Wiz did not withdraw the finding, and it changed the framing on the day of publication. Its blog carries an update posted at 19:57 UTC on 17 August describing Copilot as "a co-author that checked the merged PR and code change" which "identified it as all-clear" without noticing the vulnerabilities, and conceding that "it's unclear whether the code-change was AI-assisted." In that account the AI's failure is one of review, not authorship: the merged pull request carried a Copilot co-signature and the injection survived it. CSO Online quotes Wiz CTO Ami Luttwak saying that clear attribution between humans and AI "is becoming a bit harder to establish", and that "just looking at co-authors of the PR is not enough."

What the two accounts share is worth separating from what they contest. Both agree the squash commit carries the Copilot Autofix co-author trailer and that the workflow was exploitable. Neither disputes that GitHub Advanced Security scanned the final revision of the pull request, extracted jira_issue.yml, and did not flag the injection — Wiz reports it as a miss, and GitHub's rebuttal is about authorship rather than about the scan. What remains unresolved is whether Copilot reviewed the vulnerable lines at all: Wiz says a review ran and passed them, GitHub says the tool had no role in them, and the logs that would settle it sit with one of the two companies. The record carries both accounts rather than choosing.

Five days, and what changed after

The repair was fast once the report landed. Wiz filed through Snowflake's HackerOne program as report #3819931 on 23 June and notified Snowflake's security team by Slack the same day; Snowflake merged PR #1402, commit 1dc7766, which replaced direct expression expansion with environment variables passed to jq as arguments. Wiz's timeline puts rotation of the Jira token on 24 June, and The Hacker News reports the same split. Wiz's own introduction, by contrast, says Snowflake remediated the vulnerability and rotated the credential "on the same day" — a discrepancy inside the primary source that the record should not paper over. The fix landed on 23 June; the rotation is dated 24 June in Wiz's table.

Disclosure ran on Snowflake's clock: Wiz dates a public disclosure deadline of 25 July 2026, thirty days after a 25 June resolution under the program's policy, and published the analysis on 17 August. Snowflake's statement to CSO Online said the company "appreciates Wiz's responsible reporting" and that it was working with Wiz to share the lessons with the industry. Neither Wiz's analysis nor The Hacker News's report carries a CVE identifier, a CVSS score or an entry in CISA's known-exploited catalogue; the flaw was a workflow configuration in a public repository, not a shipped library, so it never entered a vulnerability database in the usual way.

What the record establishes, and what it does not

The archive classifies this as a research finding rather than a deployment event, with high severity, a confidence grade of A, confirmed AI involvement and recorded real harm; its date, 17 August 2026, is the day Wiz published, and the incident itself spans 18 to 23 June. The established core is narrow and checkable: a public workflow interpolated attacker-controlled text into a shell command, its guard condition compared against a property that is null on that event, a Jira token sat in the same step, an autonomous agent exploited it, and Snowflake merged a fix and rotated the credential within a day.

The parts that are inference rather than record are the ones casual retellings tend to flatten. Copilot Autofix is documented as a co-author of the pull request and is not documented as the author of the vulnerable lines; the AI-versus-AI framing that carried the first news cycle was withdrawn in part by the reporting organisation within hours and rebutted by GitHub. Whether the merged pull request's AI review looked at jira_issue.yml is still an open factual question, not a settled one. And the extent of access, while described in detail by Wiz, has not been independently audited: no Jira permissions, workflow run or audit record has been made public.

The fix pattern is the one GitHub's own guidance had recommended since July 2025 — pass untrusted issue data into an environment variable and hand it to jq as an argument, rather than expanding it inside a run block. Snowflake's merged commit does exactly that, and the corrected handling remains on the default branch. For anyone reading the record as a precedent, the durable finding is about attribution rather than about injection: when a pull request carries several humans and several agents, the co-author trailer cannot tell you who wrote a line, and both Wiz and GitHub ended up saying so in different words.