How JFrog’s AI-Research Bot Found OSS CI/CD Vulnerabilities to Prevent Shai Hulud 3.0

Recent incidents have proven that Continuous Integration (CI) workflows are the new battleground for software supply chain attacks. Security Pitfalls in GitHub Actions workflows, such as the unsanitized use of pull request (PR) data, can allow attackers to execute malicious code during CI runs with devastating consequences.

For example, the high-profile “S1ngularity” attack on the Nx project, which led to the leakage of 83,000 secrets in August 2025, was traced to this exact type of flaw: a workflow that allowed code injection via an unsanitized PR title, combined with the high privileges of the pull_request_target trigger. This enabled attackers to steal npm publishing tokens from the workflow and release trojanized packages. A follow-on campaign, the “Shai-Hulud” worm, similarly abused CI pipelines to exfiltrate secrets from hundreds of repositories, even triggering a “dead man’s switch” wiper in some variants. These instances underscore the severe risks: If an attacker can run code in a project’s CI with write-access tokens, they can compromise the entire supply chain.

The hard part isn’t understanding the risk; it’s finding these workflow flaws at scale, before they get exploited. That’s why JFrog built RepoHunter, an AI-powered security research bot designed to proactively detect CI/CD workflow exploitation patterns (“Pwn Requests”) across open source, long before they become the next Shai-Hulud-style campaign.

Over the past three months, JFrog used RepoHunter to proactively identify CI/CD vulnerabilities and responsibly alert project maintainers across open-source repositories. Recently, attackers launched a malicious campaign using the hackerbot-claw bot, taking over seven repositories belonging to Microsoft, DataDog, the CNCF, and popular open source projects such as Trivy. The attack used similar AI-assisted techniques as RepoHunter, demonstrating how the same technology can be weaponized by AI against the open-source supply chain.

In this post, we present 13 cases that were fixed by maintainers after JFrog’s responsible disclosure. They demonstrate real “Pwn Request” scenarios, where untrusted PR metadata, branch names, or attacker-controlled scripts trigger remote code execution inside GitHub CI pipelines. The impact extends beyond code repositories to threaten global financial systems, critical AI infrastructure, mobile and embedded devices, scientific publishing platforms, JavaScript language standards, and network infrastructure relied upon by billions of users worldwide.

JFrog intends to publish a follow-up technical deep dive on how RepoHunter is built and how it validates findings once remediation is complete across the affected projects.

Why CI/CD is the New Target

Recent incidents have proven that Continuous Integration (CI) workflows are the new battleground for software supply chain attacks. Security Pitfalls in GitHub Actions workflows, such as the unsanitized use of pull request (PR) data, can allow attackers to execute malicious code during CI runs with devastating consequences.

The “Shai Hulud” attacks marked a definitive turning point for the JavaScript ecosystem. By hijacking long-lived, static npm tokens of prolific maintainers, attackers were able to inject malicious payloads into widely used packages, effectively turning the npm registry into a distribution hub for malware.

Problem: the fragility of secrets

Most npm developers still rely on static npm tokens stored in GitHub Actions secrets or local environment variables. This created two major vulnerabilities:

• Persistence: If a token was leaked, it remained valid indefinitely (or until manually revoked), giving attackers a permanent back door.
• Scope: These tokens often lacked granular permissions, meaning one compromised secret could jeopardize an entire portfolio of packages.

NPM Solution: trusted publishing

In response to the Shai Hulud fallout, npm introduced Trusted Publishing. This model moves away from static, long-lived secrets in favor of short-lived, identity-based authentication.

Instead of storing a password or token, you define a trust relationship between npm and your CI/CD provider (like GitHub Actions).

With Trusted Publishing, there is no static secret that can be stolen by attackers, and the root of trust has been moved to the CI/CD.

This begs the question: Is CI/CD an infallible root of trust?

What Is a “Pwn Request” / GitHub Actions CI Takeover?

A “pwn request”, or CI takeover via pull request, is a class of vulnerability where:

1. An attacker opens a pull request (or triggers a workflow via a comment/label) from a fork or branch they control.
2. The projectʼs GitHub Actions workflow runs in a privileged context (e.g., base repository permissions, access to secrets, high-scope GITHUB_TOKEN).
3. Attacker-controlled input is executed in that context (e.g. PR branch code, PR title/body, branch name, or config that runs shell commands).
4. The runner executes the attackerʼs code with the same permissions and secrets as the workflow, leading to remote code execution (RCE) in CI.
5. From there, attackers can exfiltrate tokens and secrets, push code, change workflows, publish packages, or move laterally across the organization.

The term “pwn request” was popularized by GitHub Security Labʼs 2021 guidance: “Preventing pwn requests”. The idea is that a seemingly “normal” pull request can “pwn” the repositoryʼs CI and, by extension, the repo and often the organization.

RepoHunter: Hunting CI Takeovers Before They Scale

Securing innovation through innovative security

RepoHunter is an AI-powered security research bot developed by JFrog to proactively identify CI/CD takeover risks across open source ecosystems.

Its objective is straightforward: Detect workflow misconfigurations that allow untrusted contributors to execute code in privileged CI contexts before attackers operationalize them.

In a recent research wave, RepoHunter identified multiple CI/CD takeover vulnerabilities across widely used open-source projects, including enterprise automation platforms, programming language toolchains, developer infrastructure, and AI frameworks.

RepoHunter dashboard showing example vulnerability findings

How Does RepoHunter Operate?

RepoHunter automates the vulnerability detection process by using a practical defense pipeline:

1. Ingestion: Crawl public repositories and their CI/CD configurations to understand the exposed attack surface.
2. Identification: Detect vulnerable workflow patterns where untrusted input intersects with elevated permissions or secret access.
3. Validation: Validate exploitability using AI and generate real-world exploitation scenarios for manual execution.
4. Disclosure: Produce detailed vulnerability reports with evidence and actionable remediation guidance.

To understand what was prevented, it is important to understand the full attack chain that RepoHunter was designed to detect.

Four Phases of a CI Supply Chain Attack

A CI supply chain attack unfolds in four distinct phases:

1. Exposure: Workflow misconfiguration creates a takeover primitive.
2. Execution: Attacker controlled input achieves code execution in CI.
3. Harvesting: Credentials are extracted from the workflow environment.
4. Propagation: Stolen credentials are used to compromise repositories, registries, and infrastructure.

Phase One: Exposure

How CI misconfigurations become supply chain entry points

Across repositories, we repeatedly observed a dangerous pattern: Workflows triggered by attacker-controlled events, using attacker-supplied input, and running with repository-level privileges.

The most common and most dangerous trigger was pull_request_target. At first glance, pull_request_target looks similar to pull_request. The difference is subtle but critical.

• pull_request runs in the context of the fork that submitted the change.
• pull_request_target runs in the context of the base repository.

That means pull_request_target workflows inherit:

• Repository secrets
• Repository level GITHUB_TOKEN permissions
• Write access, if configured

While this enables maintainers to run privileged automation in response to pull requests, misconfiguration allows untrusted contributors to influence privileged execution.

Another common misconception revolves around approval settings. Many maintainers enable “Require approval for external contributors,” assuming it protects them. While this applies to pull_request triggers, it does not prevent immediate execution for:

• pull_request_target
• issue_comment
• workflow_run

Github Workflow Approval Documentation

RepoHunter’s automation detects patterns across all these triggers, allowing us to flag vulnerabilities before they are exploited. Details on specific vulnerabilities disclosed within issue_comment and workflow_run will be shared in future blogs.

Other structural issues compound the risk:

• Permission inheritance
  Workflows without an explicit permissions block inherit repository defaults. Many repos historically set defaults to “Read and write,” giving every workflow implicit write access.
• Credential persistence
  By default, actions/checkout uses persist-credentials: true, writing the active GITHUB_TOKEN into .git/config. That’s a well-known issue in Github checkout action; an attacker who achieves code execution can extract and reuse this token outside the job context (while the Job is still active), often without the maintainers’ knowledge.
• Test repository trap
  Low-visibility repositories labeled “test”, “sandbox”, or “experimental” frequently store organization-level secrets, package publishing rights, or cloud credentials. Compromising one such repo often means compromising the entire organization.

These misconfigurations form the exposure layer. Once exposure exists, exploitation becomes straightforward.

Phase Two: Execution

Three repeatable CI exploitation patterns

Across all vulnerabilities identified by RepoHunter, exploitation followed three consistent patterns. Each of these patterns is explored in depth, including full PoC of vulnerabilities found in dedicated technical writeups linked below.

1, Test-Based Execution

The workflow checks out the PR head and executes test code or scripts controlled by the attacker that are executed as part of the testing CI process.

2. Build-Scripts and Installer-Based Execution

The workflow checks out the PR head and executes build scripts that are attacker-controlled such as npm, make, Gradle, cargo, Python, etc as part of the build CI process.

3. Branch and Config Injection

Without proper escaping or sanitization, a malicious branch name or config file controlled by the attacker can trigger arbitrary command injection as part of the workflow script or any other tool use.

Phase Three: Harvesting

What attackers extract after CI compromise

Once an attacker achieves remote code execution inside a privileged CI workflow, the next step is credential harvesting.

In practice, this means systematically searching the environment for secrets:

• The first target is GITHUB_TOKEN. If it has contents: write or broader permissions, it can be used for repository takeover and workflow modification.
• Personal Access Tokens and GitHub App private keys are even more powerful. They often grant organization wide access and can be used to pivot laterally.
• Package publishing tokens are another high value target. npm tokens, PyPI tokens, Cargo registry tokens, and Docker Hub credentials allow attackers to publish malicious versions of widely used components.
• Cloud credentials are frequently present as repository or organization secrets. AWS access keys, GCP service account keys, Azure service principals, or OIDC based identity federation permissions can transform a CI compromise into a cloud infrastructure compromise.

In environments using self hosted runners, the risk increases further. RCE may inherit instance roles, managed identities, or network access to internal systems.

At this stage, the attacker has everything needed to move beyond a single repository.

Phase Four: Propagation

From Repository Compromise to Ecosystem Impact

Credential reuse is the multiplier.

• With repository write access, attackers can inject malicious workflows to establish persistence.
• With package publishing tokens, they can release trojanized versions of trusted components.
• With container registry credentials, they can replace images used in production deployments.

Cloud credentials enable storage manipulation, artifact replacement, and broader infrastructure access.

A single unsafe workflow can therefore cascade into:

• Organization-wide repository compromise
• Registry-level package poisoning
• Developer environment infection
• Cloud infrastructure manipulation
• Downstream CI compromise

This is how a supply chain worm propagates; automation turns misconfiguration into systemic risk.

RepoHunter CI\CD Takeover Summary

Project	Vulnerability & Severity	Supply Chain Impact
Ansible Enterprise IT automation platform used by Fortune 500 companies and open source maintainers alike.	GHSA-fwqj-x86q-prmq Critical	Compromise of Ansible platform packages or modules could allow attackers to inject malicious automation scripts, impacting configuration management and deployment pipelines across thousands of enterprises globally.
P4 language Program language  for network switches. Widely used in SDN, data center, and networking device toolchains.	GHSA-6cw7-hxfh-8×94 Critical	Malicious modifications could propagate into SDN environments of major enterprises such as Google, AT&T, and Intel. enabling attackers to manipulate network traffic or disrupt critical infrastructure.
Petgraph Popular Rust graph library used in applications spanning algorithms, data science, and networking.	Critical	Poisoned versions can affect hundreds of downstream Rust crates and applications, potentially exposing sensitive data, corrupting analytics pipelines, or introducing vulnerabilities in widely used systems.
QGIS Open source geospatial information system (GIS) platform used by governments, municipalities, and research institutions.	CVE-2026-24480 Critical	Compromised QGIS releases could inject malicious scripts into GIS workflows, impacting critical mapping, urban planning, or governmental projects at a national or municipal scale.
Sdkman Widely used developer toolchain manager for JVM SDKs.	GHSA-cprm-c872-3fw7 Critical	Supply chain compromise could distribute malicious SDKs or scripts, directly affecting the Java developer ecosystem and potentially introducing vulnerabilities into millions of enterprise and open source applications.
tc39/proposal-amount JavaScript standards proposal repository.	GHSA-43vf-c68r-43mr Critical	Manipulation of proposals or tooling could introduce vulnerabilities into the JavaScript ecosystem, affecting billions of websites and applications, and shaping unsafe language behaviors across the global developer community.
Telepresence CNCF open source tool for Kubernetes developers enabling local development in remote clusters.	GHSA-gc3r-m7gq-495f Critical	Compromise could distribute malicious binaries or container images, allowing attackers to affect cloud-native development workflows and introduce risks into enterprise Kubernetes environments.
Typst Official registry for the Typst typesetting language.	GHSA-j5gp-pf74-5pj6 Critical	Poisoned Typst packages could propagate into downstream typesetting projects, academic workflows, and enterprise document automation pipelines, affecting integrity and availability of published materials.
Xorbitsai Open source AI inference and model-serving framework, often deployed in LangChain sandbox environments.	Critical	Malicious PyPI packages or Docker images could compromise AI models, LangChain applications, or enterprise AI services, spreading to downstream frameworks and affecting AI-driven decision-making.
Eclipse-theia Eclipse open source framework for cloud-based IDEs.	CVE-2026-1699 Critical	Compromise could inject malicious code into cloud or desktop IDEs, impacting developers’ environments and potentially spreading malware to enterprise projects or open source repositories.
Tencent Mobile and embedded AI inference framework.	GHSA-c44p-qr97-jccv High	A supply chain attack could affect production AI features in massively deployed apps like WeChat (1.4B+ users), causing model poisoning or data leakage in end-user applications.
Ceph Distributed storage platform (Ceph).	GHSA-p433-fp4g-pc2c High	Malicious changes could propagate to cloud providers, enterprise storage deployments, or downstream distributions, risking data integrity, availability, and sensitive information exposure.
Parse-community Open source Backend-as-a-Service server.	GHSA-6w8g-mgvv-3fcj Medium	Compromised Parse Server packages could inject backend vulnerabilities into numerous mobile and web applications, allowing attackers to manipulate data, exfiltrate sensitive information, or disrupt service operations.

 

While this blog covers a total of 13 vulnerabilities: 10 Critical, 2 High, and 1 Medium, in different OSS, RepoHunter found more vulnerabilities that were responsibly reported and remediated in other GitHub repositories of organizations like SAP and RedHat.

Hypothetical Example: A Shai-Hulud-Style CI Worm

The cases in this post were responsibly reported and, in most instances, fixed. The potential “catastrophe” is what happens if attackers find the same patterns first and automate them across ecosystems.

Realistic cascade, in the style of Shai-Hulud, based on the privilege-escalation mechanics we demonstrated across multiple repositories.

Who gets hit (contributors, developers, users)

• Maintainers: triage flood, emergency rotations, key revocations, and long-term trust rebuilding.

• Contributors’ PRs/issues become an execution surface (especially with issue_comment), and their forks become the staging ground for compromise narratives.
• Developers pull compromised packages, container images, CLIs, or build tools into local dev + CI environments.
• End users experience downstream impacts through compromised applications, infrastructure, or services built on poisoned components.

What if attackers had abused the vulnerabilities before RepoHunter disclosed them?

​​These vulnerabilities were discovered in repositories that sit at the core of modern software infrastructure: enterprise automation, programming language ecosystems, developer toolchains, package registries, AI inference frameworks, and repositories tied to future language standards.

If exploited, attackers could inject malicious code into trusted CI/CD pipelines, which distribute build artifacts, packages, containers, and developer tools across the global software supply chain.

The blast radius could span government systems, large corporations, open-source projects, academic research environments, websites, and cloud services. For example, enterprise automation platforms like Ansible operate infrastructure across industries, P4 compiler ecosystems power programmable networking used by major technology companies, and developer tools like SDKMAN or Telepresence run directly on millions of developer machines and CI runners.

Compromising distribution hubs, such as Typst packages, or widely used libraries, like petgraph, could cascade into downstream dependencies used in websites, SaaS platforms, and research tooling. Even repositories connected to JavaScript standardization (TC39 proposals) sit upstream of technologies used across the entire web.

A successful CI compromise in these upstream projects could therefore propagate malicious code across entire developer ecosystems and production systems worldwide, creating a SolarWinds- or “Shai-Hulud”-scale supply-chain event in modern CI/CD infrastructure.

Vulnerability Deep Dive: Ansible Platform

Vulnerability: GHSA-fwqj-x86q-prmq

Severity: Critical

Repository: ansible/ansible.platform

From pull request to organization-wide compromise

Ansible is one of the most widely adopted open source automation platforms in the world.

It’s used by all shapes of companies, from massive enterprises to open source repositories across industries, which rely on it to automate infrastructure provisioning, configuration management, and application deployment.

Ansible references in open-source code

RepoHunter identified a workflow in the ansible/ansible.platform repository that used pull_request_target, checked out untrusted pull request code, and executed it within the trust boundary of the base repository.

Ansible pull_request_target vulnerable workflow

More critically, two sensitive tokens were exposed during execution:

• AAP_GATEWAY_REPO_TOKEN, used for cross repository access and enabling lateral movement.
• GITHUB_TOKEN, configured with full access to Ansible organization packages.

GITHUB_TOKEN configured with Ansible packages access.

Because actions/checkout persisted credentials by default, the active GITHUB_TOKEN was written into the runner’s git configuration, making extraction trivial once code execution was achieved.

From that point, the escalation path was straightforward.

An attacker could publish malicious packages across the Ansible GitHub organization, modify workflows to establish persistence, forge build artifacts, or manipulate releases to hide ongoing compromise.

This is not theoretical, but rather a viable organization-level supply chain compromise affecting a globally trusted automation platform.

All Ansible users pulling packages from github.com/orgs/ansible/packages (currently millions of downloads), as well as other secrets detected in the Ansible organisation, were at risk.

Ansible org packages page with 29 packages and millions of downloads

RepoHunter identified the vulnerability before it could be exploited in the wild, and it was remediated through responsible disclosure.

What RepoHunter Prevented

By identifying these CI takeover vulnerabilities before public exploitation, RepoHunter prevented potential compromise across:

• Enterprise automation ecosystems
• Programming language toolchains
• AI inference frameworks
• Developer infrastructure
• Cloud connected build systems

Keep your CI/CD safe with JFrog Advanced Security

JFrog Advanced Security can analyze GitHub workflow files and detect CI/CD vulnerabilities, such as a pull_request_trigger mixed with untrusted code execution. Start a free trial or book a demo today.

Identifying a vulnerable GitHub workflow in the JFrog Platform

Conclusion – Securing CI as Critical Infrastructure

CI is no longer just a build system. It is an identity broker, a release authority, and a distribution gateway. That makes workflow configuration a security control, not a convenience feature.

Read the Manual: Modern CI/CD automation has seen significant improvements, and while these tools are fast and enable rapid innovation, they must be secure.

Know exactly what you are doing and why. Each misconfiguration can cause a catastrophic chain reaction, turning a simple pull request into a gateway for organization-wide compromise.

Organizations must treat pull_request_target with extreme caution. Explicit least privilege permissions must be defined in every workflow. Sanitize all untrusted inputs, such as metadata or code, before use. Credential persistence should be disabled when not required. Privileged automation must be separated from untrusted execution. Most importantly, CI must be continuously audited. Manual review is not enough at ecosystem scale.

We built RepoHunter because this problem cannot be solved reactively. It must be hunted proactively. The next supply chain worm does not need a zero day; it just needs one unsafe workflow and automation.

In this case, we found it first.