The Hidden Danger of Git Tags: How Shadow Commits Compromise CI/CD Pipelines

TLDR: Attackers are abusing GitHub's "Fork Network" to inject malicious code into CI/CD pipelines without leaving a trace in the main repository's commit history. By using "shadow commits" and overriding mutable git tags, they can execute arbitrary code on CI runners to exfiltrate secrets. Security teams must stop using git tags for pipeline triggers and switch to immutable commit SHAs immediately to prevent this supply chain attack.

The industry has spent years obsessing over dependency confusion and malicious packages, but we have largely ignored the CI/CD configuration itself. The recent CVE-2025-30099 incident involving the tj-actions/changed-files repository is a masterclass in how attackers exploit the trust we place in open-source tooling. This wasn't a simple case of a compromised account; it was a sophisticated, multi-stage campaign that leveraged the fundamental way GitHub handles forks and tags to turn a popular utility into a secret-stealing machine.

The Mechanics of the Shadow Commit

Most developers assume that if they reference a git tag in their workflow, they are pulling code from a known, verified state. The attacker here understood that GitHub’s "Fork Network" is a platform feature, not a git primitive. When a repository is forked, the fork exists in the same network, and commits pushed to that fork are technically accessible from the upstream repository if you know the hash.

The attacker created a "shadow commit"—a commit pushed to a fork that never appears in the main repository's branch history. Because git tags are just pointers to a commit hash, the attacker simply overrode an existing tag (like v1) to point to their malicious commit hash instead of the legitimate one.

When a CI/CD pipeline triggers, it fetches the tag. If your workflow uses uses: tj-actions/changed-files@v1, the runner resolves that tag to the attacker's commit hash. The runner then executes the malicious code in the context of your repository, granting the attacker access to your environment variables and secrets. This is a classic OWASP A06:2021 – Vulnerable and Outdated Components scenario, but applied to the infrastructure layer rather than a library.

From Recon to Exfiltration

The attack flow demonstrated in the research is a blueprint for lateral movement. The attacker didn't just target one repo; they performed reconnaissance to find maintainers with access to multiple organizations. By compromising a maintainer's Personal Access Token (PAT), they gained the ability to push these shadow commits across the network.

Once the malicious code is running on the CI runner, the payload is surprisingly simple. The research highlighted a Python-based memory dumper that iterates through /proc/[pid]/maps and /proc/[pid]/mem to scrape environment variables directly from the process memory.

# Simplified logic of the exfiltration payload
import os
# Iterate through process directories to find secrets
for pid in os.listdir('/proc'):
    if pid.isdigit():
        try:
            with open(f'/proc/{pid}/environ', 'rb') as f:
                # Scrape and exfiltrate environment variables
                secrets = f.read()
                # ... exfiltration logic ...
        except:
            continue

This technique bypasses standard log masking because it doesn't rely on echo statements that CI platforms might scrub. It reads the raw memory of the runner, ensuring that even if you have "secret masking" enabled, the attacker still gets the plaintext values.

Testing for This Vulnerability

If you are a pentester, your engagement should focus on the CI/CD configuration files. Look for any uses directive that references a tag rather than a full 40-character commit SHA. If you find one, you have a potential entry point.

During an assessment, you can verify this by checking if the repository allows forks and if the CI/CD pipeline is configured to run on pull requests from those forks. Tools like Gato-X or Zizmor are essential for auditing these workflows at scale. If you can push a commit to a fork and trigger the pipeline, you have effectively demonstrated the risk. The impact is total compromise of the CI runner, which usually includes access to cloud provider credentials, deployment keys, and production environment secrets.

Defensive Hardening

The fix is straightforward but requires a cultural shift in how we manage pipelines. Stop using tags. They are mutable and inherently insecure for security-sensitive operations. Every uses directive in your .github/workflows/*.yml files must point to a specific, immutable commit SHA.

# Bad Practice
- uses: tj-actions/changed-files@v1

# Good Practice
- uses: tj-actions/changed-files@a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0

Additionally, implement strict branch protection rules that prevent the overriding of tags and limit the ability of external contributors to trigger workflows that have access to secrets. GitHub is currently experimenting with Immutable Releases, which is a step in the right direction, but until that is universal, you are responsible for pinning your dependencies.

We are operating in an ecosystem where the tools we trust are often the most dangerous vectors. The next time you see a workflow using a version tag, treat it as a critical finding. The attacker is likely already watching the fork network, waiting for you to make a mistake.