JFrog Security Research

Part 1 - pull_request_target Exploitation

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

The JFrog Security Research team has identified multiple critical vulnerabilities across open source ecosystems that follow the same structural misconfiguration pattern in CI/CD workflows. These issues are not isolated mistakes. They stem from workflows that execute untrusted pull request content in privileged contexts, creating severe supply chain risk.

In a separate blog, we explained how we built an AI agent to systematically detect these misconfiguration patterns at scale, what signals it looks for, and how such vulnerabilities can escalate from a single repository to organization-wide compromise.

At the center of these cases is the GitHub Actions trigger pull_request_target, where pull requests run in the context of the base repository, inheriting its secrets and permissions. The full vulnerability details are also explained in the main blog.

Each short blog in this series will cover one specific exploitation class and provide concrete exploitation analysis, this blog starts with “Test-Based Execution”.

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

Vulnerability: CVE-2026-24480
Severity: Critical
Repository: qgis/QGIS

The repository included a GitHub Actions workflow triggered by pull_request_target.
The workflow configuration included:

on:
  pull_request_target:
  push:

Because the workflow:

  • Was triggered by pull_request_target
  • Checked out and executed pull request code
  • Ran pre-commit test checks that were controlled by the PR submitter

An attacker could submit a malicious pull request that executes arbitrary commands within the CI environment, inheriting the repository’s workflow privileges.

In this case, the pull request code was executed through pre-commit run, allowing direct command execution inside the workflow.

The workflow environment included:

  • GITHUB_TOKEN with contents: write and additional repository privileges

These permissions enabled direct repository modification from within the CI environment.

All stages from getting RCE to repository compromise:

  1. Submit malicious pull request
  2. Trigger pull_request_target workflow execution
  3. Execute arbitrary commands through pre-commit
  4. Extract Github_Token from the environment
  5. Use token to create new branches and modify the repository state
  6. Modify workflows to exfiltrate additional secrets or pivot further

The QGIS repository contains the source code of a widely used geographic information system. Governments, research institutions, and enterprises rely on QGIS for geospatial analysis, mapping, infrastructure planning, and operational decision making.

QGIS is distributed and repackaged by downstream organizations, including Linux distributions, internal enterprise mirrors, and government environments. A compromise of upstream CI integrity undermines trust in build artifacts and forces downstream rebuilds and incident response efforts. Public analytics indicate millions of QGIS application launches per month, and the repository maintains significant community adoption. The real impact is defined by the widespread institutional reliance on trusted builds and release artifacts. Compromising its CI pipeline could directly affect operational integrity across public and private sector environments worldwide.

Vulnerability: GHSA-cprm-c872-3fw7
Severity: Critical
Repository: sdkman/sdkman-cli
Fix: PR #1487

The repository included a pull-requests.yml workflow triggered by pull_request_target.
The workflow checked out the pull request code and executed:

./gradlew clean test

gradlew is a shell script stored in the repository that is used in this workflow for testing. This means that executing it allows any commands in the script to run with the workflow’s privileges.

Because the workflow:

  • Was triggered by pull_request_target
  • Checked out untrusted pull request code
  • Executed gradlew with repository privileges

An attacker could submit a pull request modifying gradlew to execute arbitrary commands. The workflow would then run these commands with full access to repository permissions.

The workflow environment included:

  • GITHUB_TOKEN with contents: write

This allowed attackers to push malicious commits, modify releases, or perform other repository-level operations.

All stages from getting RCE to repository compromise:

  1. Submit malicious pull request modifying gradlew
  2. Trigger pull_request_target workflow
  3. Achieve arbitrary command execution in CI
  4. Access repository write permissions via GITHUB_TOKEN
  5. Push malicious commits or modify releases

The sdkman-cli repository powers the SDKMAN! toolchain for the JVM ecosystem, enabling developers to install, manage, and switch between Java, Kotlin, Groovy, and other JVM SDKs. Its workflows are central to maintaining reliable developer environments for millions of JVM developers worldwide.

A compromise in sdkman-cli could allow attackers to inject malicious commands into a trusted developer tool, potentially affecting millions of downstream development environments. With roughly 6.6k stars and 644 forks, the repository is widely adopted, and the workflow misconfiguration creates a high-risk attack vector that could directly impact the JVM developer ecosystem.

Vulnerability: GHSA-j5gp-pf74-5pj6
Severity: Critical
Repository: typst/packages
Fix: Commit 7dcd854

The repository included a test_pr.yml workflow triggered by pull_request_target.

The workflow checked out untrusted pull request code and executed Rust code as part of the CI testing process.

Because the workflow:

  1. Was triggered by pull_request_target
  2. Checked out the untrusted pull request code
  3. Executed Rust test code controlled by the pull request author

An attacker could submit a malicious pull request containing a tainted .rs file. When the workflow executed the test pipeline, the attacker controlled Rust code would run automatically with repository privileges.

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

The workflow environment included sensitive credentials, including:

  • AZURE_PACKAGE_CREDENTIALS - Allows upload/modify packages in Azure CDN
  • GH_PRIVATE_KEY - Provides full GitHub App authentication
  • GH_APP_ID + GH_INSTALLATION_ID - Provides token minting capabilities across the Typst organization

All stages from getting RCE to repository compromise:

  1. Submit a malicious pull request containing tainted Rust test code
  2. Trigger pull_request_target workflow
  3. Execute the attacker controlled code during test execution
  4. Extract GitHub App key and cloud credentials from the CI environment
  5. Mint GitHub App tokens with organization-wide scope
  6. Modify repositories and poison package distribution infrastructure

We successfully demonstrated token exfiltration and repository write access, confirming full repository compromise under CI privileges.

The typst/packages repository functions as the official registry and distribution hub for the Typst language ecosystem. Compromise here is amplified because it is not merely a code repository, it is a distribution surface.

Typst distributes packages through organization-level infrastructure, including GitHub Packages and cloud-backed distribution channels. The presence of GitHub App credentials and Azure publishing secrets means a CI compromise can extend beyond a single repository and impact multiple projects within the organization.

487k total downloads of Typst GitHub organization packages that use “typst”

An attacker who exfiltrates GitHub App keys can mint tokens for any repository accessible to that App, enabling lateral movement and multi-repository compromise. Combined with package publishing credentials, this creates the potential to poison official packages consumed by downstream users.

As Typst adoption grows in academic and technical publishing environments, compromise of its official distribution hub can cascade through document pipelines, templates, and automated build systems. Because registries are trust anchors, poisoning them transforms a single pull request vulnerability into ecosystem-wide supply chain risk.

Vulnerability: CVE-2026-1699
Severity: Critical
Repository: eclipse-theia/theia-website

The repository included a workflow triggered by pull_request_target (.github/workflows/preview.yml) that checked out untrusted PR code and executed attacker-controlled scripts.

Workflow snippet:

# Executes build/test scripts on PR code
npm install
npm run build

Because the workflow ran with full repository privileges, a malicious PR author could execute arbitrary code in the base repository context.

  • GITHUB_TOKEN - Full repository & org access (modify code, workflows, packages, GitHub Pages, CI/CD)
  • DEPLOY_PREVIEW_TOKEN - Cross-repository deployment access
  • NODE_AUTH_TOKEN - Publish/modify packages

Steps demonstrated during testing:

  1. Submit malicious PR with crafted code in package.json.
  2. Trigger pull_request_target workflow.
  3. Execute attacker-controlled scripts in CI.
  4. Exfiltrate GITHUB_TOKEN, DEPLOY_PREVIEW_TOKEN, and NODE_AUTH_TOKEN.
  5. Push backdoored packages to eclipse-theia org (~37k downloads).
  6. Modify repository content and workflows, including GitHub Pages.

The eclipse-theia/theia-website repository powers official website deployment and CI workflows for Theia IDE, a widely used cloud and desktop IDE.

Packages in the org include theia-ide (~11.5k downloads), theia-blueprint (~1.94k downloads), and others (~37k total).
Poisoned workflows or packages could propagate into multiple Eclipse projects (eclipseche-theia-*) and production environments.
Developer workstations, CI/CD pipelines, published packages, and GitHub Pages could be affected.

The real impact stems from organization-wide CI privileges, ecosystem-level package distribution, and the role of Theia IDE in Eclipse, meaning compromise could cascade across millions of developers.