Wiz Red Agent

Wiz's autonomous AI red-teaming agent found and exploited a GitHub Actions command-injection flaw in Snowflake's public connector repo, exfiltrating live Jira credentials via an out-of-band callback

Wiz Research's autonomous "Red Agent" AI red-teaming tool independently discovered and exploited a GitHub Actions script-injection vulnerability in Snowflake's public snowflake-connector-net repository, introduced via PR #1218 (18 June 2026) and undetected by GitHub Advanced Security despite the flaw sitting directly in the analysed workflow. The injectable pattern entered the jira_issue.yml workflow in commit 094038e and went live when PR #1218 was squash-merged as commit 4a1b8ce: "the injectable pattern was added to jira_issue.yml in commit 094038e and became live when PR #1218 was squash-merged as commit 4a1b8ce" (Wiz Research, 2026-08-17), allowing an unauthenticated actor to inject shell commands via a crafted GitHub issue title interpolated unsanitised into the workflow's shell step.

When the agent's initial payload (using # to comment out the rest of the line) hit an unexpected bash syntax error (the comment character also consumed the closing parenthesis of the shell's TITLE=$(...) construct) it did not stop or fail. Instead it "autonomously analyzed the syntax execution error" and "adjusted its payload to use ; echo ' to properly close the shell block, and" (Wiz Research, 2026-08-17) retried, recovering from its own exploitation error without human direction. Within seconds, Wiz's listener received an out-of-band callback from the GitHub Actions runner carrying base64-encoded Jira API credentials tied to a qa@snowflake.net account. Wiz writes that "our listener received the callback from a GitHub Actions runner", a callback "containing base64-encoded credentials" (Wiz Research, 2026-08-17). Snowflake patched the workflow the same day of disclosure (23 June 2026, commit 1dc7766/PR #1402), restoring safe env: variable interpolation and jq --arg parsing.

This is a further, vendor-independent data point in the CI/CD trust-boundary thread already covered here around GitHub Actions script injection. The autonomous-error-recovery behaviour (diagnosing a failed exploitation attempt and adjusting the payload without human intervention) is itself a capability marker worth tracking regardless of which side deploys it: the same recovery loop that let Wiz's defensive tool self-correct mid-exploit is available to an offensive operator running comparable tooling against any organisation's own public CI/CD workflows. Triage: GitHub Actions workflows that interpolate untrusted issue or pull-request titles directly into shell steps, rather than passing them through env: variables with jq --arg-style safe parsing, are the systemic pattern this flaw exemplifies, an audit of any organisation's public-repository workflows for this exact interpolation shape is the actionable takeaway, independent of this specific incident.