2026-08-19·10 min read·sota.io team

A GitHub Actions Bug Leaked Snowflake's Jira Token. GitHub and Wiz Can't Agree Who Wrote It — Here's What CRA Article 13 Cares About Instead

On August 17, 2026, security firm Wiz disclosed that its autonomous "Red Agent" system had found and exploited a script-injection vulnerability in a GitHub Actions workflow belonging to snowflakedb/snowflake-connector-net — a repository Snowflake ships as a public product, not an internal tool. The bug let anyone open a GitHub issue with a booby-trapped title and get arbitrary commands executed on Snowflake's CI runner. Wiz's report says the exploit handed it a live Jira API token with read access to Snowflake's engineering, security-compliance, and bug-bounty projects, for a window of roughly five days before Snowflake patched it.

That's a bad bug on its own. What made it a story is who Wiz says wrote it: a commit that carried the flaw into the default branch lists "Copilot Autofix powered by AI" as a co-author. GitHub disputes that framing directly, saying its internal review shows a human engineer wrote the vulnerable lines and that Copilot Autofix never reviewed them. Both companies have now published conflicting accounts of the same commit history, and — as one outlet covering the dispute put it — only one of them holds the logs that would settle it.

This post is not trying to referee that fight. It's here because the CRA doesn't need the fight settled to be relevant, and most of the coverage skipped straight past the actual regulatory question: what does the Cyber Resilience Act say about how a "product with digital elements" gets built, regardless of whether the hand on the keyboard was human or AI?

What actually broke, mechanically

The vulnerable file was .github/workflows/jira_issue.yml, a workflow that fired automatically whenever someone opened an issue on the repo — meaning any unauthenticated GitHub user could trigger it. Per Wiz's writeup, the workflow took the untrusted issue title and interpolated it directly into a shell command:

# the pattern that broke: raw GitHub Actions expression inside a shell string
run: |
  TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/.../.../')

Because ${{ github.event.issue.title }} is substituted by GitHub's template engine before the shell ever sees the line, an issue title containing a single quote can break out of the echo string and inject arbitrary shell commands — a well-documented GitHub Actions anti-pattern that GitHub's own security documentation has warned against since mid-2025. The fix is equally well documented: pass untrusted values through an intermediate environment variable first, so the shell treats them as data instead of code —

# the fix: untrusted value never touches the shell as a literal
env:
  ISSUE_TITLE: ${{ github.event.issue.title }}
run: |
  TITLE=$(printf '%s' "$ISSUE_TITLE" | sed 's/.../.../')

Per Wiz, that safe env:-variable pattern is exactly what the vulnerable change removed. An August 2025 commit refactored the workflow away from it; a June 18, 2026 pull request (#1218) then squash-merged that change onto the default branch, and the squash-merge commit is the one listing Copilot Autofix as a co-author. Wiz's Red Agent — its own autonomous exploitation tool — found the resulting hole, chained it into a working exploit, retrieved the Jira token, and reported the whole thing to Snowflake through HackerOne on June 23. Snowflake merged a fix and rotated the token the same day. Wiz also states that GitHub Advanced Security scanned the final revision of the workflow and did not flag the injection.

If you maintain any GitHub Actions workflows that consume github.event.issue.title, github.event.pull_request.title, github.event.comment.body, or similar user-controlled template expressions directly inside a run: shell block, this is worth a five-minute grep across your own repos today, independent of anything else in this post.

Why GitHub and Wiz disagree — and why it's a real disagreement, not spin

Wiz's public account treats the Copilot Autofix co-author line as evidence that GitHub's own AI review tool wrote or approved the unsafe change. GitHub's response, relayed to press covering the dispute, is more specific than a denial: it says the commit that actually introduced the vulnerable jira_issue.yml logic was authored by a named Snowflake engineer back in August 2025, months before the June 2026 merge, and that the Copilot Autofix co-author tag attached only when GitHub squashed multiple commits into one during the PR #1218 merge — a mechanical side effect of how squash-merges roll up co-author trailers from every commit in the PR, not a record of who wrote which lines. GitHub's position is that this records participation somewhere in the pull request's history, not authorship of — or review of — the specific lines that broke.

That is a genuinely unresolved factual dispute, not a case of one side obviously being right. It hinges on internal GitHub telemetry about what Copilot Autofix actually analyzed, which neither Wiz nor outside observers can independently verify from the public commit history alone. Treat any headline stating flatly that "AI wrote the Snowflake vulnerability" as unconfirmed — and treat "no AI was involved at all" as equally unconfirmed, since GitHub's own account still leaves Copilot Autofix's co-author line on the merge commit unexplained beyond "squash-merge behavior."

What's not in dispute — and it's the part that matters for CRA purposes

Regardless of who wrote the unsafe line, three facts are corroborated across Wiz, GitHub, and independent reporting: the vulnerable pattern was a regression from a safe pattern that already existed in the repo; the change passed through a pull-request merge without a human catching the regression; and GitHub Advanced Security's automated scanning of the final code did not catch it either. That's the actual lesson, and it holds even in the version of events most favorable to GitHub: a defense-in-depth pipeline that included code review and automated security scanning still let a known, previously-avoided injection pattern back into a shipped product's CI/CD.

What CRA Article 13 actually requires here — with the dates that usually get mangled

snowflake-connector-net is a software connector Snowflake distributes to customers — a "product with digital elements" squarely inside the Cyber Resilience Act's scope (Regulation (EU) 2024/2847). Article 13, "Obligations of manufacturers," requires manufacturers to design, develop, and produce such products in accordance with the essential requirements in Annex I, informed by a documented cybersecurity risk assessment covering the product's intended use and expected lifetime — and to exercise due diligence when integrating third-party and open-source components so they don't compromise the product's security. Annex I's vulnerability-handling requirements (Part II) go further: manufacturers must identify and document vulnerabilities and components — including a software bill of materials — and address and remediate vulnerabilities without delay.

Here's the date correction that most CRA coverage of "AI wrote a vulnerability" stories will get wrong, because it's genuinely easy to conflate with the CRA's other deadlines: Article 13's substantive obligations, along with the rest of Annex I's essential requirements and CE-marking, only become fully enforceable EU-wide on December 11, 2027. That's a different date from the CRA provision most people associate with "vulnerability incidents" — Article 14's 24-hour/72-hour/14-day reporting duty to ENISA and national CSIRTs, which applies earlier, from September 11, 2026 — and different again from Chapter IV's conformity-assessment-body notification rules (Articles 35–51), which apply from June 11, 2026. A Jira-token leak via CI/CD script injection, discovered and disclosed as it was here, isn't itself a CRA Article 14 reportable event unless it meets that article's specific "actively exploited vulnerability" or "severe incident" thresholds for a shipped product — Wiz's exploitation here was authorized security research against Snowflake's own infrastructure, not an in-the-wild attack on the connector's end users, so it doesn't trigger that clock. What Article 13 and Annex I do already establish, ahead of full 2027 enforceability, is the standard manufacturers are expected to be building toward now: a secure development lifecycle where regressions like this don't reach a default branch unnoticed, whoever — or whatever — proposed the change.

The practical point Article 13 forces, regardless of the attribution fight

CRA Article 13 doesn't ask "did an AI write this?" It asks whether the manufacturer's development process — the actual sequence of risk assessment, review, and testing — was adequate to the product's risk profile. That framing sidesteps the entire Wiz/GitHub dispute, and it's the more useful one operationally too: "an AI reviewed it," "a human reviewed it," and "our scanner passed it clean" are all, on their own, insufficient evidence of a compliant secure-development process if the actual outcome is a known-bad pattern reaching production. A PR co-authored or reviewed by an AI coding tool should raise your scrutiny threshold for security-sensitive changes — CI/CD workflow files, auth logic, anything touching secrets — not lower it, precisely because "the AI said it's fine" is not yet an auditable security control under any framework, CRA included.

Same-week checklist

Grep your GitHub Actions workflows for untrusted github.event.* expressions used directly inside run: shell blocks (issue/PR titles, comment bodies, branch names) — the exact regression pattern here.
For any hit, move the untrusted value into an env: variable before the shell ever touches it; don't rely on sed-based escaping applied after GitHub's template expansion, which is what still let the Snowflake exploit through.
Don't treat "GitHub Advanced Security scanned it clean" as sufficient sign-off for workflow files that consume untrusted external input — this incident is a documented case of exactly that scan missing the injection.
If your team uses AI coding assistants (Copilot, Claude Code, or others) for CI/CD or auth-adjacent changes, add an explicit human-review gate for that category specifically — regardless of how the Wiz/GitHub attribution dispute resolves, unresolved provenance is itself a reason for more scrutiny, not less.
If you're a CRA-covered manufacturer, confirm your documented cybersecurity risk assessment (Article 13) explicitly covers your CI/CD and release pipeline, not just the shipped product's runtime code — Annex I's due-diligence language covers how the product is built, not only what ships.

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Join the waitlist View plans