JFrog Security Research

Part 2 - pull_request_target Exploitation

Barak Haryati, Senior Director of Product Security at JFrog | March 5, 2026

In this exploitation pattern, 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.

Vulnerability: Issue: #950
Severity: Critical
Repository: petgraph/petgraph
Fix: PR #932

The repository included a release workflow triggered by pull_request_target.

The workflow configuration executed cargo build on untrusted pull request code and exposed sensitive environment variables:

on:
  pull_request_target:
jobs:
  release-plz-pr:
    permissions:
      contents: write
    env:
      CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}  # CRITICAL!

In Rust, build.rs scripts are executed during compilation. This means that running cargo build does not only compile code, it executes arbitrary Rust code defined in build.rs.

Because the workflow:

  • Was triggered by pull_request_target
  • Checked out and built pull request code
  • Executed cargo build, which runs build.rs

We successfully submitted a malicious pull request containing a modified build.rs file. When the workflow executed cargo build, the attacker controlled build script ran with repository privileges and access to release credentials.

In this case, the build.rs script executed successfully during CI, proving arbitrary command execution inside the workflow environment.

The workflow environment included:

  • CARGO_REGISTRY_TOKEN, allowing publication to crates.io.
  • GITHUB_TOKEN with contents: write permissions

This combination enabled both repository modification and potential registry level compromise.

All stages from getting RCE to repository compromise:

  1. Submit malicious pull request containing modified build.rs
  2. Trigger pull_request_target workflow
  3. Execute arbitrary commands during cargo build
  4. Extract CARGO_REGISTRY_TOKEN from environment
  5. Publish a backdoored version of the petgraph crate
  6. Downstream Rust projects depending on petgraph automatically install the malicious release during dependency updates

We successfully demonstrated build.rs execution and branch creation, proving write access under CI privileges.

The petgraph repository maintains one of the most widely used graph libraries in the Rust ecosystem. It is commonly treated as the default crate for graph data structures and algorithms, embedded in infrastructure components, developer tooling, and performance-sensitive services across the ecosystem.

With hundreds of millions of downloads on crates.io, petgraph is widely embedded in other Rust libraries and applications. Any company pinning or updating Petgraph as a dependency could unknowingly consume a trojanized release. Because build.rs executes during compilation, downstream developers would not need to explicitly run malicious code, simply building a project that depends on a compromised crate executes the attacker’s payload.

Vulnerability: GHSA-43vf-c68r-43mr
Severity: Critical
Repository: tc39/proposal-amount

The repository included a pr-preview.yml workflow triggered by pull_request_target.
The workflow checked out pull request code and executed npm ci with granting elevated permissions.

Because the workflow:

  • Was triggered by pull_request_target
  • Checked out untrusted pull request code
  • Executed npm ci, which runs hooks

An attacker could submit a malicious pull request embedding arbitrary commands inside lifecycle scripts. When the workflow executed npm ci, the attacker controlled hooks would run automatically with repository privileges.

In this case, arbitrary command execution was successfully demonstrated within the CI environment.

The workflow environment included:

  • GITHUB_TOKEN with contents: write and PullRequests: write
  • Docker credentials (index.docker.io auth)

All stages from getting RCE to repository compromise:

  1. Submit malicious pull request modifying ECMAScript proposal documents with malicious code
  2. Trigger pull_request_target workflow
  3. Execute attacker controlled commands during npm ci
  4. Extract authentication token to webhook.site from the CI environment
  5. Create new branches and modify repository content
  6. Persist control by modifying workflows or injecting additional logic

The tc39/proposal-amount repository hosts a JavaScript language proposal under the TC39 process, which governs ECMAScript evolution. While it primarily contains specification text and preview tooling, it represents a high-trust surface within the JavaScript standards ecosystem.

TC39 repositories function as governance anchors for the JavaScript language specification. A compromise here does not simply affect a documentation project; it undermines trust in the standards development process itself. An attacker with write access could modify proposal documents, inject misleading specification examples, or alter preview workflows in ways that influence reviewers and implementers. Because TC39 proposals guide browser vendors, Node.js maintainers, and enterprise implementers, trust in these repositories carries ecosystem-wide implications.

Although public adoption metrics are modest, the strategic importance is significant. TC39 proposals shape the future of JavaScript, powering billions of websites and applications. Compromising such a repository introduces both technical supply chain risk and governance/trust risk across the global JavaScript ecosystem.

Vulnerability: GHSA-gc3r-m7gq-495f
Severity: Critical
Repository: telepresenceio/telepresence
Fix: Commit add782c

The repository included an image-scan workflow triggered by pull_request_target.
The workflow checked out pull request code and executed:

make save-tel2-image

In projects that rely on Makefiles, invoking make executes targets defined inside the repository’s Makefile. These targets can contain arbitrary shell commands.

Because the workflow:

  • Was triggered by pull_request_target
  • Checked out untrusted pull request code
  • Executed make, which runs repository-defined targets

An attacker could submit a malicious pull request modifying the Makefile target. When the workflow executed, make save-tel2-image, the attacker controlled commands would run automatically with repository privileges.

In this case, arbitrary command execution was successfully demonstrated within the CI environment.

The workflow environment included:

  • GITHUB_TOKEN with contents: write and additional write repository privileges

All stages from getting RCE to repository compromise:

  1. Submit a malicious pull request modifying the Makefile target
  2. Trigger pull_request_target workflow
  3. Execute attacker-controlled commands via make
  4. Extract the authentication token from the CI environment
  5. Push a new branch to the upstream repository
  6. Modify workflows or releases to persist control

We successfully demonstrated branch creation, proving full repository compromise under CI privileges.

The telepresence repository maintains a widely used Kubernetes development tool that enables developers to run services locally while connected to remote clusters. It is commonly installed across engineering teams and integrated into CI pipelines.

Telepresence is distributed through multiple channels, including binaries, containers, and package managers, and is broadly adopted in cloud-native development workflows. With thousands of stars and hundreds of forks, it represents a significant component of Kubernetes developer tooling.

A compromised release could propagate malicious code into developer workstations, CI runners, and cluster access workflows. Because developer tooling often receives broad internal trust and cluster-level permissions, such a compromise can become an organization-wide infection vector across engineering environments.

Vulnerability: GHSA-c44p-qr97-jccv
Severity: High
Repository: Tencent/ncnn
Fix: PR #6444

The repository included a workflow (compare-binary-size.yml) triggered by pull_request_target that checked out untrusted pull request code and executed CMake builds.

Because CMake’s execute_process can run arbitrary commands, an attacker controlling the PR code could execute arbitrary commands on the CI runner.

  • GITHUB_TOKEN with pull-requests:write - Manipulate PRs (approve/close/reopen/label/comment), trigger label-based CI/ChatOps automation

The workflow ran with limited repository tokens, which protect against immediate takeovers. But RCE, combined with PR write privileges, allows attackers to manipulate automation that may trigger workflows with broader secrets, leading to significant escalation.

All stages from getting RCE to repository compromise:

  1. Submit a malicious PR with crafted CMake commands.
  2. Trigger pull_request_target workflow.
  3. Execute arbitrary commands via CMake execute_process.
  4. Use pull-requests:write to manipulate PRs (labeling, approving, reopening) to influence automated workflows.

Tencent/ncnn is a neural network inference framework used to build and deploy AI models in mobile applications and other environments. The workflow compromise allows arbitrary commands to run during CI builds, affecting the integrity of artifacts produced by the repository.

While the repository has thousands of stars and forks, compromise may affect production AI features in widely deployed applications (e.g., WeChat, 1.4B+ users). Potential escalation may lead to the manipulation of CI pipelines,the injection of backdoors, or the influence on downstream builds that consume ncnn components, amplifying the impact beyond the single repository.

Any build pipelines, SDKs, or applications that rely on ncnn could inherit malicious behavior, leading to downstream security and operational risks across production mobile AI deployments.

Vulnerability: GHSA-6w8g-mgvv-3fcj
Severity: Medium
Repository: parse-community/parse-server
Fix: PR #9966

The workflow used pull_request_target and ran npm install on PR code. NPM lifecycle scripts (preinstall, postinstall) in package.json execute automatically.

To successfully exploit the vulnerability, we added a malicious preinstall script to the PR that dumped git configuration data from the runner.

  • GITHUB_TOKEN including contents: read, pull-requests: write and issue: write.

Even with limited permissions, attackers can:

  • Act as an “authorized” actor in the repository collaboration surface: comment, label, close/reopen PRs and issues.
  • Trigger or influence ChatOps / issue_comment-style automation, potentially chaining into other workflows or higher-trust paths
  • Introduce persistent backdoors if a malicious PR is merged, including malicious GitHub Actions workflows

Note: This vulnerability affected only the CI infrastructure, not the package itself.

Parse Server powers backend infrastructure for numerous mobile and web applications. While the repo has thousands of stars and forks, compromise could affect downstream projects relying on PR/issue automation or CI workflows.

Malicious workflows could manipulate PRs or issues, trigger automated processes, and potentially pivot to other repositories or workflows within the organization or ecosystem.

The GitHub repository contains thousands of stars and forks, and npm reports 40,000+ weekly downloads for parse-server (as of Jan 2026).