Not Just a Pipeline Leak: Reconstructing Real Attack Behind tj-actions

Not Just a Pipeline Leak: Reconstructing the Real Attack Behind tj-actions

Speakers: Aviad Hahami

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=-CSbWpj_IZM

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Aviad%20Hahami%20-%20Not%20Just%20a%20Pipeline%20Leak%20Reconstructing%20the%20Real%20Attack%20Behind%20tj-actions.pdf

Overview

On March 14, 2025, an attacker compromised the popular GitHub Actions repository tj-actions/changed-files and injected code that printed CI runner secrets to job logs. The widely reported story was that this was a supply chain attack aimed at harvesting credentials from the thousands of repositories using this action. Aviad Hahami's DEF CON talk argues that this narrative — while true — missed the actual attack. The credential leakage was a side effect, not the goal. Through systematic reconstruction of the attack timeline, attacker infrastructure, and the chain of compromised repositories, Hahami reveals a sophisticated, multi-stage supply chain attack targeting a specific high-value downstream victim, with the tj-actions compromise being one link in a longer chain. The talk is a forensic investigation into CI/CD supply chain attacks and demonstrates techniques for graph-based attack reconstruction.

Background

▶ Watch: We will then go over how we at Palato Networks were able to trace and uncover... (3:44)

GitHub Actions is the CI/CD platform embedded in GitHub. Repositories define workflows — YAML files that run jobs in response to events like pushes or pull requests. These workflows commonly reference external "actions" — reusable workflow components published by third parties. The tj-actions organization publishes a collection of widely used helper actions; changed-files is among the most popular, used by thousands of repositories to identify which files changed in a commit.

Supply chain attacks targeting CI/CD pipelines have become increasingly prevalent. When a developer's workflow includes uses: tj-actions/changed-files@v1, they are pulling and executing code from an external repository. If that external repository is compromised, every workflow run that references it executes attacker-controlled code with the permissions of the GitHub Actions runner — which may include access to secrets, credentials, and the ability to push to protected branches.

The March 2025 incident triggered immediate community response: CVEs were created, organizations issued warnings, and thousands of repositories scrambled to audit their Actions dependencies. But Hahami's investigation, starting from the public incident data and systematically expanding outward, revealed that the attacker had been operating in this supply chain for far longer and with a more specific objective than mass credential harvesting.

Key Findings

▶ Watch: movement into the review dog organization. (16:11)

• The tj-actions compromise was not the beginning of the attack chain. Hahami traced the attack back through multiple previously compromised GitHub Actions repositories, establishing that the attacker had systematically worked through the dependency graph of the CI/CD supply chain to reach tj-actions.
• The credential dumping was likely unintentional or a diversionary artifact. Printing secrets to logs is extremely noisy — it immediately triggers detection. A sophisticated attacker pursuing credential harvesting would not do this. The log dumping may have been an error, or may have been an intentional distraction while the real objective was pursued elsewhere.
• The attacker used a compromised personal access token (PAT) from a GitHub Actions bot account as the initial foothold — not a vulnerability in GitHub itself. Token theft or social engineering was the likely entry point.
• Graph theory techniques are essential for attack reconstruction in dependency-heavy ecosystems. The speaker applied graph analysis to the GitHub Actions dependency graph to map the attacker's lateral movement through the supply chain.
• A specific downstream target was identified as the likely true objective of the attack chain, based on the intersection of compromised repositories' dependency graphs.

Technical Deep Dive

▶ Watch: So this is how it's being done in the GitHub world. (20:15)

The GitHub Actions dependency graph as an attack surface: GitHub Actions workflows reference other actions by repository and tag. This creates a directed dependency graph: if Repo A's workflow uses Action B, and Action B is compromised, then Repo A's pipeline runs attacker code. The attacker's optimal strategy is to compromise an action with maximum downstream reach — an action used by high-value targets.

Reconstructing the attack timeline:

Hahami established the following sequence:

1. The attacker gained initial access through a compromised PAT belonging to a GitHub Actions bot. The specific PAT's origin was traced through analysis of the GitHub audit log artifacts that were publicly observable.
2. Using this access, the attacker modified workflow files in the compromised repository, adding code to print environment variables (which include ACTIONS_RUNTIME_TOKEN and repository secrets injected into the environment) to job logs.
3. The injection targeted the run step of the changed-files action such that any repository running this action would execute the exfiltration code.
4. Critically, the attacker also had access to additional repositories in the tj-actions organization and made similar modifications.

The broader chain: The speaker's graph analysis revealed that the PAT used to compromise tj-actions originated from or was associated with another compromised repository earlier in the chain. By examining contributors, workflow bot accounts, and their cross-repository permissions, Hahami traced a lateral movement path through multiple repository compromises leading to the tj-actions foothold.

Identifying the true target: Using the dependency graph, Hahami identified which high-value repositories (based on indicators like: cryptocurrency project, high-security product, sensitive data handling) depended directly on tj-actions. The intersection of this set with other signals from the attack — such as timing, the specific repositories that received targeted modifications — pointed to a specific downstream target as the likely objective.

EBPF and CI/CD forensics: The speaker's day-job background in eBPF engineering informed the forensic methodology. He discussed the use of eBPF-based tracing tools on CI runners to capture process execution, file I/O, and network activity at the kernel level, enabling more detailed analysis of what code executes during a CI job than log-level inspection alone.

GitHub's audit log as evidence: GitHub's audit log (accessible to organization administrators) records push events, permission changes, and OAuth token usage. This log was the primary forensic source for establishing the attacker's movement. The speaker described specific artifact patterns in the audit log that indicate compromised PAT usage.

Demo / Proof of Concept

▶ Watch: Since DJ actions change files ran the malicious code, the CI pick (28:40)

The talk included:

• A timeline visualization of the attack chain, showing the sequence of repository compromises and their chronological relationship.
• A graph visualization of the GitHub Actions dependency network, highlighting the compromised nodes and showing how the attacker traversed the graph.
• A demonstration of the attacker's injected code, explaining exactly how secrets were exfiltrated from runner environments.
• An example of the forensic analysis technique — using public GitHub API data and audit log artifacts to reconstruct attacker movement.

The speaker used Jupyter notebooks and custom Python tooling for the graph analysis and dependency mapping.

Defensive Implications

▶ Watch: me show you some uh pictures from behind the scenes. (34:47)

Pin Actions to specific commit SHAs, not mutable tags. The standard uses: owner/action@v1 syntax tracks whatever the maintainer pushes to the v1 branch or tag. An attacker who compromises the action repository can update that reference to point to malicious code. Pinning to a specific commit SHA (e.g., uses: tj-actions/changed-files@a536aa37...) means the workflow will not execute any new code pushed after the pin.

Audit your Actions dependency graph. Tools like zizmor, actionlint, and the GitHub dependency graph can enumerate all external Actions your workflows depend on. Treat this as you would a software dependency audit — identify unused dependencies, outdated pins, and dependencies from low-reputation or low-activity accounts.

Apply least-privilege to GitHub Actions tokens. The default GITHUB_TOKEN should have only the permissions the workflow actually needs. Restricting token permissions via the permissions key in workflow YAML limits the blast radius of a compromised action.

Monitor CI runner secrets exposure. Never inject secrets into environment variables unless absolutely necessary. Use GitHub's secrets store with ${{ secrets.NAME }} references, and audit which workflows have access to which secrets.

Treat CI/CD infrastructure as attack surface. CI runners execute arbitrary code. Network segmentation, short-lived credentials, and ephemeral runner environments limit lateral movement from a compromised CI job.

Supply chain monitoring: GitHub's Dependabot and third-party tools can alert on changes to pinned dependency SHAs. Any change to a pinned action should be reviewed before allowing the new code to run.

Key Takeaways

1. The publicly narrated story of the tj-actions incident — mass credential harvesting — was a distraction from, or a side effect of, a more targeted supply chain attack.
2. The attacker worked systematically through the GitHub Actions dependency graph to reach a high-value downstream target, compromising multiple repositories along the way.
3. Printing secrets to logs is noisy and inconsistent with sophisticated credential harvesting; the true attack objective was likely a specific downstream target identified through graph analysis.
4. Graph theory and dependency analysis are essential tools for forensic reconstruction of supply chain attacks in CI/CD ecosystems.
5. Pinning GitHub Actions to commit SHAs is the most effective single mitigation against this class of attack.
6. The scope of supply chain risk in CI/CD is significantly larger than most organizations appreciate; the full dependency graph — including transitive action dependencies — must be audited.

About the Speaker(s)

▶ Watch: Instead, the attacker printed it to the logs. (42:24)

Aviad Hahami is a security researcher and eBPF engineer at aos.io. He previously worked as a security researcher at Palo Alto Networks. His research interests include bug bounty, graph theory, and lacto-fermentation. This was his second DEF CON talk. He delivered the presentation with his parents in the audience — their first time seeing him speak at DEF CON, having not believed the first talk happened without seeing it in person.