Skip to content

Uncovering and Responding to the tj-actions Supply Chain Breach

Varun SharmaAshish Kurmi

Incident responders detail the compromise of popular GitHub Actions workflows, tracing malicious pull requests and automated credential harvesting.

Summary

Overview: Varun Sharma and Ashish Kurmi, co-founders of Step Security, deliver a detailed technical post-mortem of the March 2024 supply chain breach affecting `tj-actions/changed-files`, a highly popular GitHub Action utilized by over 23,000 public repositories and thousands of enterprise environments. The speakers trace the incident from its initial discovery via runtime anomaly detection through technical triage, vulnerability analysis, and community response. They reveal the mechanics of "impostor commits" across GitHub forks, process memory dumping of the CI/CD runner daemon, and evasion of secret-masking filters to expose sensitive enterprise credentials.

Key Topics: - Detection of the `tj-actions/changed-files` breach via CI/CD runtime anomaly monitoring (Harden-Runner) - Mechanics of GitHub "impostor commits" and release tag manipulation across cross-repository forks - Dumping `Runner.Worker` process memory using `memdump.py` to extract runtime secrets - Bypassing GitHub Actions log secret masking via double Base64 encoding and enterprise incident response

Technical Details: On Friday, March 14, Step Security's runtime CI/CD protection platform (Harden-Runner) triggered an automated alert on an unauthorized outbound network connection originating from a GitHub Actions workflow executing `tj-actions/changed-files`. Investigation revealed that the action—trusted by major organizations including Microsoft, Meta, GitHub, Hugging Face, and HashiCorp—had been weaponized to exfiltrate pipeline credentials, culminating in a high-severity CVE and a CISA Cybersecurity Advisory. The attack leveraged a unique architectural behavior of GitHub: commits pushed to an unprivileged fork exist in the global Git object database of the upstream network, allowing them to be referenced via the original repository's API. After obtaining repository write access (linked to compromised bot credentials), the threat actor created an "impostor commit" in a fork and repointed legitimate release tags (including `v35` and major version pointers) to the malicious commit SHA in the fork, instantly propagating malicious code to all workflows tracking those tags.

The backdoored commit executed an obfuscated Base64 shell command that fetched `memdump.py` from a public GitHub gist. Designed for Linux runners, the Python script enumerated active host processes to locate `Runner.Worker`, the core GitHub Actions runner process responsible for holding pipeline environment variables and injecting secrets into execution steps. By reading `/proc/$PID/mem`, `memdump.py` extracted the runner's memory space and regex-searched for GitHub's internal secret storage patterns. To evade GitHub's automated log scrubber—which detects and redacts raw secrets and single Base64-encoded strings—the attackers applied double Base64 encoding to the harvested credentials before writing them to standard output. Because double-encoded strings bypassed GitHub's masking filters, plain credentials appeared unmasked in public build logs for external harvesting. The incident was subsequently linked by independent researcher Adnan Khan and research teams at Wiz and Palo Alto Networks to a coordinated supply chain campaign targeting other open-source automation actions, including Reviewdog.

Key Takeaways: The `tj-actions` breach highlights the extreme vulnerability of modern CI/CD pipelines to upstream dependency tampering. Organizations must enforce runtime security monitoring on build runners (using solutions like Step Security Harden-Runner, Falco, Wazuh, or Tetragon) to baseline and detect anomalous outbound network connections, process spawning, and sensitive file writes. Security teams must mandate pinning third-party GitHub Actions to immutable full commit SHAs rather than mutable Git tags or release branches, enforce strict marketplace action allowlists, and establish structured incident response procedures to identify exposed workflows, audit public build logs, and rapidly rotate leaked credentials.

(AI summary — Gemini Flash)

Related talks