Most teams would not have caught the tj-actions/changed-files compromise from their own logs. They would have learned about it from public advisories, then needed to know which workflows used the action and which secrets those workflows could see. This checklist tests exactly those two abilities.
What happened?
The GitHub advisory for CVE-2025-30066 says attackers changed several existing version tags of the action to point to a malicious commit. Workflows that referenced those tags ran code that extracted secrets from the runner process memory and printed them in the Actions logs. The advisory gives the exposure window as 14 to 15 March 2025, lists 45.0.7 and earlier as affected, and 46.0.1 as fixed. It also reports that more than 23,000 repositories used the action.
CISA's alert adds that the compromise was possibly enabled by a separate compromise of reviewdog/action-setup@v1 (CVE-2025-30154) and that it added both CVEs to its Known Exploited Vulnerabilities Catalog. Its guidance was to audit for use of the action in the affected window, look for leaked secrets, and rotate anything exposed.
The advisory credits StepSecurity with detection, via an unexpected outbound request seen by its runner monitoring. That detail is the lesson: the signal was network egress from a build, not a failed test.
Which controls would have mattered?
Pinning. The malicious change worked because tags can be moved. A workflow that referenced the action by full commit SHA kept running the old, known code. Tags are convenient and mutable, SHAs are neither.
Secret scope. The payload could only print what the runner held. Workflows that received every repository secret exposed more than workflows that received only what each job needed.
Log exposure. Public repositories made printed secrets readable by anyone. Treat Actions logs as public output for public repos.
Egress visibility. A build that suddenly calls a new external host is a signal. Few teams watch for it.
What to do
- Search all repositories for uses of third-party actions and list them in one inventory.
- Pin every third-party action to a full commit SHA, and update by pull request with review of the diff.
- Give each workflow the least permissions it needs through the permissions key, and avoid passing all secrets to jobs that do not use them.
- Prefer short-lived credentials (OIDC to your cloud) over long-lived keys stored as secrets.
- For public repositories, assume Actions logs are world readable.
- Monitor or restrict outbound network access from runners, and alert on new destinations.
- Keep an incident runbook that lists, per repository, which secrets exist and who can rotate each within hours.
- When an advisory lands, check workflow runs in the stated window for unexpected output.
- If exposure is possible, treat the secrets as compromised and rotate them right away, as both GitHub and CISA advise.
- Add a dependency review step for workflow files, not only application code.
How does an inventory help here?
The first question on the day was "do we use it, and where." An organization with a searchable inventory of workflow dependencies answered in minutes. Our CI/CD demo shows how pipeline checks can run as part of a build.
Open the full demo at /demos/ci-cd-actions.
Quick check
Why did pinning to a tag not protect users?
The attackers repointed existing tags to a malicious commit, so a workflow referencing a tag pulled the new code. A full commit SHA identifies one exact version of the code and cannot be moved.
What should you do if a secret may have been printed in a log?
Treat it as compromised and rotate it immediately. Both the GitHub advisory and CISA recommend this, and removing the log line later does not undo prior exposure.
Sources
- GitHub Advisory GHSA-mrrh-fwg8-r2c3 (CVE-2025-30066), fetched 18 October 2026.
- CISA: Supply Chain Compromise of Third-Party GitHub Action, CVE-2025-30066, fetched 18 October 2026.
Last reviewed: 18 October 2026.
