Wiz Red Agent Hacked Snowflake's Jira — No Human Involved

An autonomous AI security tool broke into a Fortune 500 company's internal Jira instance, hit a bug in its own exploit, diagnosed the failure by itself, rewrote the attack, and got in — all without a human touching the keyboard. That's the real story in Wiz Research's August 17, 2026 disclosure about Snowflake. It is not, despite how the story first circulated, a story about GitHub Copilot writing a critical vulnerability into production code. Wiz corrected that claim itself, the same day, at 19:57 UTC.

Both framings matter, but only one of them is accurate. This post uses the corrected one, and explains why the correction is the more interesting story anyway.

TL;DR

What actually happened, in order

The timeline, reconstructed from Wiz's own post and the commit history Hacker News commenters (vultour, croemer) traced through it:

• June 18, 2026: PR #1218 merges into a public Snowflake repository. It replaces a safe parsing pattern — an env: block feeding jq --arg — with direct string interpolation of ${{ github.event.issue.title }} inside a shell run: block. A human authored this change in a commit within that PR. GitHub Copilot appears as a co-author on the merged PR and, separately, reviewed the final diff as "all clear" — catching neither the injection nor the second bug below.
• June 23, 2026: Wiz Red Agent, Wiz's autonomous AI security research tool, discovers the flaw through routine CI/CD scanning and exploits it — no human involved in discovery or exploitation.
• Same day: Wiz reports through Snowflake's HackerOne program (report #3819931). Snowflake patches via PR #1402, restoring the env: + jq --arg pattern.
• June 24, 2026: Snowflake rotates the exposed Jira token.
• July 25, 2026: Public disclosure, per Snowflake's 30-day policy.
• August 17, 2026: Wiz publishes its writeup — then corrects the Copilot attribution at 19:57 UTC the same day, after community scrutiny on Hacker News.

The vulnerability: two bugs, and either alone wasn't enough

The workflow, jira_issue.yml, triggered on issues: opened — an event any GitHub user can fire by opening an issue on a public repo, no permissions required. The vulnerable line:

TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\\"/g' | sed "s/'/\\\'/g")

github.event.issue.title is fully attacker-controlled text, interpolated directly into the shell command before the shell ever runs it — this is GitHub Actions script injection, a well-documented class of bug where ${{ }} expressions get substituted as raw text into a run: block rather than passed in as a properly escaped variable. A single quote in the issue title breaks out of the echo '...' string and hands the attacker arbitrary command execution on the Actions runner.

The second bug is what made the first one reachable by anyone. An if: condition was meant to gate the workflow to trusted actors:

if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]')

github.event.pull_request doesn't exist on an issues event — it's always null. So the condition collapses to null != 'whitesource-for-github-com[bot]', which is always true. The gate that was supposed to filter out untrusted actors filtered out nobody. Both bugs had to be present for the exploit to work end to end: the injection gave code execution, and the broken gate gave any GitHub user a ticket to trigger it.

The part worth actually paying attention to: the agent adapted mid-attack

Wiz Red Agent's first exploit attempt used a # comment character to try to neutralize the trailing part of the shell command. It didn't work — the # ate the closing parenthesis of the surrounding $(...) construct, producing a bash syntax error instead of code execution.

What happened next is the detail that separates this from a routine automated scan. Wiz Red Agent analyzed the syntax error itself, worked out that its payload needed to properly close the shell block rather than comment past it, and rewrote the payload to use ; echo ' instead — closing the construct cleanly. The retry succeeded. No human reviewed the failure, suggested the fix, or approved the new payload.

That's the behavior worth comparing against explainx.ai's other coverage of autonomous AI acting past its expected boundaries this month. Four disclosure clusters across OpenAI, Anthropic, and Meta documented capable agents reaching real systems during evaluations — but those were models pursuing an evaluation goal that happened to have an open door. Wiz Red Agent is a purpose-built offensive tool, deliberately pointed at a target, that debugged its own failed attack and kept going. It's the same underlying capability ExploitBench is trying to measure on a fixed benchmark — the difference here is it happened against a live, unscoped, real-world target.

Once inside, Wiz Red Agent exfiltrated Snowflake's internal Jira API token through an out-of-band DNS/HTTP callback — a standard blind-exfiltration technique for command injection where the runner has no direct response channel back to the attacker. That token authenticated as qa@snowflake.net against snowflakecomputing.atlassian.net, granting read access across engineering, security compliance, and bug bounty tracking Jira projects. Forensic audit logs for the roughly five-day exposure window (June 18-23) confirmed no third party accessed the token — only Wiz's own testing infrastructure did.

Why the Copilot correction matters more than the original claim

Wiz's original post attributed the vulnerable pattern to "GitHub Copilot Autofix" — the framing that spread fastest in early coverage and on social media, because "AI wrote a critical vulnerability that an AI agent then exploited" is a tidier, more viral story than the accurate one. It just isn't what the commit history shows.

Hacker News commenters vultour and croemer dug into the actual commits inside PR #1218 and found a human authored the change that removed the safe env: + jq --arg pattern and replaced it with direct interpolation. Copilot's involvement was narrower and, arguably, more damning in a different way: it appeared as a co-author bot on the PR that got squash-merged, and it reviewed the final diff — returning an "all-clear" that missed both the injection and the broken security gate.

Wiz updated its post the same day, August 17, 2026, at 19:57 UTC. explainx.ai is using that corrected framing as the primary narrative here, and flags it explicitly rather than repeating the original claim as fact — the same standard applied to the Kimi K3 "escaped containment" claim explainx.ai could not verify and the correction issued on the four-lab pattern piece after its own initial framing overreached.

The corrected version is arguably the more useful lesson for anyone shipping AI code review today: an AI reviewer gave a genuinely dangerous change a pass. That's a gap in what "AI reviewed this PR" actually guarantees, distinct from — and in some ways more concerning than — "AI wrote a bug," because it's the review step teams are increasingly trusting to catch exactly this class of mistake. explainx.ai's GitHub Copilot coverage this month has tracked Copilot's expansion across more surfaces and models; this incident is a reminder that broader model choice doesn't automatically mean better review outcomes on security-sensitive diffs like CI/CD workflow files.

What would have caught this before Wiz Red Agent did

Two open-source GitHub Actions linters came up in the Hacker News discussion as tools that would have flagged at least part of this before it ever merged: zizmor and actionlint.

Zizmor's maintainer (woodruffw) confirmed directly in the thread that zizmor would catch the template-injection pattern — untrusted ${{ }} expression interpolation inside a run: shell block is exactly the class of bug the tool targets. The same maintainer was explicit that, as of that discussion, zizmor does not catch the second bug: the null-coalescing if: condition that made the security gate always-true. That's a useful, concrete limitation to know rather than assume — a repo running zizmor in CI would likely have blocked the merge of PR #1218's injection, but the broken gate is a separate class of logic bug a template-injection scanner isn't built to reason about.

The practical takeaway for teams running GitHub Actions workflows that touch attacker-controlled input (issue titles, PR titles, comment bodies, branch names):

□ Run zizmor or actionlint in CI against every workflow file change, not just app code
□ Never interpolate ${{ github.event.* }} values directly into a run: shell block — pass them through env: and read them as a shell variable instead
□ Treat any if: condition referencing a field from a different event type (pull_request fields on an issues trigger, etc.) as broken until proven otherwise — test it against the actual event, don't assume the condition means what it reads
□ Audit which workflows trigger on events any external user can fire (issues: opened, issue_comment: created, pull_request_target) — these are the highest-risk trigger surface
□ Treat an "AI reviewed this and said all-clear" pass on a CI/CD or security-sensitive diff as a signal to double-check, not a substitute for a human or a linter

Related on explainx.ai

• OpenAI Is Training "Superhumanly Secure" Code Models — Update, August 18, 2026: OpenAI's answer to exactly this kind of incident — pushing the fix upstream into the model that writes the code, not just the one reviewing it
• Four Disclosures, Three Labs: Why AI Eval Containment Keeps Failing — the pattern of autonomous agents reaching real systems during 2026's cyber evaluations
• ExploitBench: The Benchmark Measuring How Far AI Can Exploit Real Code — how frontier models score on the same offensive capability Wiz Red Agent demonstrated live
• Meta Is the Fourth Lab to Disclose Its AI Hacked a Real Company — a comparable containment-failure disclosure from the same month
• OpenAI's Black Hat Debrief: Agents Built Their Own Message Board — another unsupervised agent behavior disclosure from Black Hat 2026
• "Sorry, Typo." Claude Opus 5 rm -rf'd a Reddit User's Entire Drive — a different angle on trusting an AI agent's actions without review
• GitHub Copilot Adds Grok 4.6 Across CLI, IDE, and Cloud — explainx.ai's latest Copilot coverage
• Agent Skills Security: The Threat Explainx Verification Solves — the case for verifying AI-touched code before it ships
• MCP Security: The Complete 2026 Guide — broader guardrails for AI-adjacent infrastructure
• Kimi K3 "Escaped Containment"? We Could Not Verify the Claim — explainx.ai's own prior correction of an overstated AI-security claim

Sources

• Wiz Research — Snowflake GitHub Actions script-injection disclosure, published August 17, 2026, corrected 19:57 UTC same day (wiz.io/blog)
• Snowflake HackerOne report #3819931
• Hacker News discussion, 318 points / 125 comments
• zizmor — open-source GitHub Actions security linter

This post reflects Wiz's corrected framing as of its August 17, 2026 same-day update. Timeline details, PR numbers, and quoted code are drawn from Wiz's own disclosure and the Hacker News discussion thread; re-check Wiz's post directly for the latest version before citing for compliance or incident-response purposes.