Skip to content

Secrets exfiltration via `pull_request_target`

Critical
DIYgod published GHSA-h87r-5w74-qfm4 Jul 9, 2025

Package

actions RSSNext/Folo (GitHub Actions)

Affected versions

< 585c6a591440cd39f92374230ac5d65d7dd23d6a

Patched versions

585c6a591440cd39f92374230ac5d65d7dd23d6a

Description

Summary

Using pull_request_target on .github/workflows/auto-fix-lint-format-commit.yml can be exploited by attackers, since untrusted code can be executed having full access to secrets (from the base repo). By exploiting the vulnerability is possible to exfiltrate GITHUB_TOKEN which has high privileges. GITHUB_TOKEN can be used to completely overtake the repo since the token has content write privileges.

Details

The pull_request_target in GitHub Actions is a major security concern—especially in public repositories—because it executes untrusted code from a PR, but with the context of the base repository, including access to its secrets.

on:
  pull_request_target:
    types: [opened, synchronize]

Along with code checkout on head.sha, an attacker is able to control the code and change the workflow to execute random code.

      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.head_ref }}
          repository: ${{ github.event.pull_request.head.repo.full_name }}

PoC

An attacker has multiple injection point inside the workflow .github/workflows/auto-fix-lint-format-commit.yml.
By changing the file package.json in the repo it's possible to execute the malicious code.
To prove this is possible we did a test by extracting the GITHUB_TOKEN. With the token extracted we were able to create a testing tag poc-v1.1.55 which has been deleted after 2 minutes.

Impact

With GITHUB_TOKEN and write permissions, an attacker is able to completely overtake the repo.

Fix

We suggest to remove pull_request_target from all the workflows and more importantly to remove/fix it in all branches that contain it, or manage to use it properly without checking out untrusted code.
We also advice to properly set the GITHUB_TOKEN permissions properly based on that the workflow needs to do, restricting what it's not necessary.

Kindly reported by @darryk10 and @AlbertoPellitteri

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

CVE ID

CVE-2025-53546

Weaknesses

No CWEs

Credits