Wiz Red Agent Breaches Snowflake’s Internal Jira Through a GitHub Actions Flaw Missed by Security Scanning

Wiz Red Agent Finds a GitHub Actions Vulnerability Inside Snowflake’s Development Workflow

An autonomous AI security research agent from Wiz discovered and exploited a critical GitHub Actions script injection vulnerability in a public Snowflake repository, according to research published by Wiz on August 17, 2026.

The vulnerability affected the snowflakedb/snowflake-connector-net repository and could allow an unauthenticated GitHub user to execute commands on a GitHub Actions runner by creating an issue containing a specially crafted title.

Wiz said its Red Agent identified the issue through its CI/CD security capabilities, exploited the vulnerability during controlled proof-of-concept testing and reached Snowflake's internal Jira environment using an exposed credential.

The vulnerability became active on June 18, 2026, when PR #1218 was merged. Wiz discovered and reported it on June 23, meaning the flaw was exposed for approximately five days before detection. Snowflake remediated the workflow on the same day it received the report.

Important clarification about GitHub Copilot

The incident should not be interpreted as proof that GitHub Copilot generated the vulnerable code.

Wiz updated its article on August 17 to clarify that Copilot was a co-author that checked the merged pull request and code change and identified it as all-clear without detecting the critical vulnerability. Wiz also stated that it remains unclear whether the specific code change was AI-assisted.

This distinction is important because the incident demonstrates a broader software security problem: AI-assisted development workflows can still contain vulnerabilities that pass existing security checks.

How the GitHub Actions vulnerability was introduced

The vulnerable workflow was jira_issue.yml. It was configured to run when a new GitHub issue was opened.

The security problem came from the way the workflow handled the issue title.

The repository previously used an environment variable together with jq --arg to process the value safely. The merged change instead placed the GitHub issue title directly inside a shell command.

A simplified representation of the vulnerable pattern is:

- run: |
    TITLE=$(echo '${{ github.event.issue.title }}' | sed '...')

The problem is that ${{ github.event.issue.title }} is expanded before the shell executes the resulting command. Because the issue title is controlled by the person creating the issue, specially crafted input could escape the intended quoted string and alter the shell command.

The existing escaping performed by sed happened too late to prevent the initial shell interpretation. Wiz therefore classified the workflow as vulnerable to script injection.

A safer approach

The repository's previous pattern passed the untrusted value through an environment variable and then processed it with jq --arg.

A simplified defensive example is:

env:
  ISSUE_TITLE: ${{ github.event.issue.title }}

run: |
  jq -n --arg title "$ISSUE_TITLE" \
    '{title: $title}'

The important security principle is to avoid directly embedding attacker-controlled data into shell source code.

For production workflows, developers should also minimise shell execution, validate untrusted input and use purpose-built tooling where possible.

Security lesson: Data supplied by an external event should remain data. It should not become part of executable shell syntax.

The security gate that did not provide protection

The workflow also contained an if: condition that appeared to restrict execution:

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

However, Wiz found that github.event.pull_request is null for an issue event.

As a result, the comparison effectively became:

null != 'whitesource-for-github-com[bot]'

Wiz concluded that the condition evaluated as true, meaning the apparent security gate did not prevent users from triggering the workflow through GitHub issues.

This illustrates why security conditions need to be evaluated against the actual event context rather than simply looking protective in source code.

GitHub Advanced Security did not flag the injection

Another significant aspect of the incident was the interaction with automated security scanning.

According to Wiz, GitHub Advanced Security analysed the final pull request revision and extracted the vulnerable jira_issue.yml workflow, but did not flag the critical injection.

This does not mean automated security scanning is ineffective. Instead, the incident shows that a security tool can analyse a vulnerable workflow without necessarily identifying every possible security issue.

The case also demonstrates the importance of combining different security approaches, including static analysis, secure coding practices, CI/CD controls, runtime monitoring and independent security testing.

Red Agent adapts during exploitation

Wiz's research becomes particularly notable when the Red Agent begins testing the vulnerability.

During its initial attempt, the agent encountered a Bash syntax error. Rather than stopping, Wiz said the autonomous agent analysed the execution error, modified its approach and successfully obtained an out-of-band callback.

Wiz reported that the resulting callback contained credentials associated with Snowflake's Jira environment.

The research demonstrated that the agent could move through several stages independently:

Discover
   ↓
Identify vulnerable workflow
   ↓
Construct test input
   ↓
Execute proof of concept
   ↓
Analyse execution error
   ↓
Adjust test
   ↓
Validate access
   ↓
Assess potential exposure

The important point is not simply that AI found a vulnerability. The agent was able to iterate after an unsuccessful attempt and continue its security investigation without human intervention, according to Wiz.

Access to Snowflake's internal Jira

During the proof-of-concept exercise, Wiz reported that the exposed Jira credential authenticated against Snowflake's Atlassian environment.

According to the research, the credential was associated with qa@snowflake.net and provided read access across engineering, security compliance and bug bounty tracking projects.

Wiz said Snowflake's subsequent investigation found no evidence of unauthorised access by outside parties during the five-day exposure window. The anomalous activity identified in the audit logs was attributed to Wiz's testing. Wiz also stated that the data accessed during its proof-of-concept testing was securely deleted.

This distinction matters. The research demonstrated what an attacker could potentially reach through the vulnerable workflow, but the investigation did not establish that an unrelated attacker had accessed the Jira environment.

Snowflake patched the issue the same day

Snowflake responded rapidly after receiving the vulnerability report.

According to Wiz, the company:

1. Patched the vulnerable workflow on June 23, 2026.

2. Restored the safer environment-variable and jq --arg processing pattern.

3. Revoked and rotated the affected Jira credential.

4. Reviewed audit logs to determine whether unauthorised access had occurred.

The vulnerability was reported through Snowflake's HackerOne vulnerability disclosure programme.

What this incident means for AI-assisted development

The incident highlights a growing challenge for organisations adopting AI-assisted software development.

AI coding tools can help developers produce and modify code, but the resulting changes still require conventional security validation. The Wiz research specifically points to a scenario where a vulnerable pattern entered a CI/CD workflow, passed the available security analysis and remained active until an autonomous security agent discovered it.

The research does not establish that Copilot wrote the vulnerable change. Instead, it shows that an AI-assisted development environment and automated security controls did not prevent the vulnerable workflow from reaching production use.

For engineering teams, the practical lesson is straightforward: AI assistance should not change the security requirements applied to code.

Every pull request should continue to receive appropriate review, testing and security analysis regardless of whether its code was written manually, generated by an AI tool or produced through a combination of both.

CI/CD security needs protection against regressions

One of the most important details in the incident was the change from a safer input-handling pattern to direct shell interpolation.

That represents a security regression.

A secure coding practice can disappear during an apparently routine code modification if the security requirement behind the practice is not explicitly enforced.

For organisations operating large CI/CD environments, this means security controls should address not only newly introduced vulnerabilities but also regressions from previously secure implementations.

Useful defensive practices include:

• Keep untrusted GitHub event data out of shell source code.

• Prefer environment variables and structured argument handling.

• Minimise the use of dynamically constructed shell commands.

• Treat GitHub Actions workflows as production security-sensitive code.

• Review changes to workflow triggers and permissions carefully.

• Use multiple layers of security analysis rather than depending on a single scanner.

• Monitor CI/CD credentials and rotate them when exposure is suspected.

• Apply least-privilege permissions to workflow identities.

• Review security-sensitive changes even when automated tools mark them as safe.

The discovery window is getting shorter

The vulnerability existed for five days before Wiz's autonomous agent discovered it.

That timeframe is important because traditional security processes often operate on longer development and vulnerability-management cycles.

The emergence of autonomous security agents could shorten the time between vulnerability introduction and discovery. For defenders, this creates pressure to improve both prevention and response.

The announcement highlights a broader industry shift toward security systems that can continuously inspect code, infrastructure and CI/CD workflows rather than waiting for periodic reviews.

For enterprises, this could mean that vulnerability remediation speed becomes increasingly important alongside vulnerability detection.

Credentials remain a critical part of the attack path

The research also demonstrates why credentials inside CI/CD environments require strict controls.

In this case, a workflow vulnerability created a route from an externally triggered GitHub event to a GitHub Actions runner. The subsequent proof-of-concept testing demonstrated access to a Jira credential available to the workflow.

Even when a credential is not directly exposed in source code, a compromised workflow can potentially provide an attacker with access to the execution environment where secrets and tokens are available.

Organisations should therefore treat CI/CD runners as security-sensitive environments and minimise the credentials available to individual workflows.

Disclosure timeline

The dates above are based on Wiz's published disclosure timeline.

Snowflake's response

Snowflake said it appreciated Wiz's responsible disclosure and collaboration through its HackerOne vulnerability disclosure programme.

The company stated that the vulnerability was immediately investigated and remediated after disclosure and that its investigation found no evidence of unauthorised access. Snowflake also said it remained focused on strengthening its software development and security practices.

Key takeaways for security teams

The Snowflake incident offers several practical lessons for organisations building with AI-assisted development tools.

1. AI-assisted code still requires human-level security standards

Whether a change is written by a developer, generated with AI assistance or reviewed by an AI system, it should receive the same security scrutiny.

2. Automated scanners are one layer, not the entire security programme

The vulnerable workflow was analysed by GitHub Advanced Security but the injection was not flagged, according to Wiz. Multiple complementary controls remain important.

3. CI/CD workflows should be treated as critical code

A workflow can have access to credentials, cloud resources and internal services. Security review should therefore extend beyond application source code.

4. Avoid direct interpolation of untrusted input

External event data should be handled as data rather than embedded directly into shell commands.

5. Reduce credential exposure

Short-lived credentials, least privilege and rapid rotation can reduce the potential impact of a compromised workflow.

6. Prepare for autonomous vulnerability discovery

The development reflects growing demand for security systems capable of continuously finding and validating vulnerabilities at machine speed.

Analysis

The most significant aspect of this incident is the interaction between two increasingly automated parts of modern software engineering.

On one side, developers are increasingly using AI-assisted tools within coding and pull-request workflows. On the other, security researchers are developing autonomous systems capable of continuously searching for weaknesses.

The result is a faster security feedback loop.

The announcement highlights a broader industry shift toward security testing that can operate continuously alongside software development. The five-day interval between the vulnerability becoming live and its discovery illustrates how quickly automated security research can operate.

However, the case also shows why automation should be layered rather than treated as a replacement for security engineering. A security scanner, an AI coding assistant and an autonomous security agent can each perform different tasks, and none should be assumed to provide complete coverage.

For enterprises, this could mean greater emphasis on secure-by-default CI/CD patterns, least-privilege credentials, strong workflow isolation and rapid remediation processes.

Conclusion

Wiz's Red Agent research demonstrates how a relatively small CI/CD code change can create a path from an externally controlled GitHub event to a privileged workflow environment.

The vulnerability in Snowflake's public repository was fixed on the day it was reported, the affected credential was rotated and Snowflake's investigation found no evidence of unauthorised external access.

The broader lesson extends beyond Snowflake.

As AI becomes more deeply integrated into software development and security operations, organisations will need security controls capable of keeping pace with both sides of that automation. AI-assisted development does not eliminate traditional secure coding requirements, while autonomous security agents may increasingly reduce the time available to attackers and defenders alike.