CVE-2025-30154 is a reviewdog/action-setup embedded malicious code vulnerability in reviewdog action-setup GitHub Action. CISA added it to the Known Exploited Vulnerabilities catalogue on 24 March 2025, which means attackers have used it in real attacks. reviewdog action-setup GitHub Action contains an embedded malicious code vulnerability that dumps exposed secrets to Github Actions Workflow Logs.
What Makes This Vulnerability Dangerous in a GitHub Action
This CVE matters because the malicious code sits inside a build-time automation component that many repositories trust implicitly. In a GitHub Actions environment, that means a single compromised or tainted action can turn routine CI activity into secret exposure at scale, especially when workflows run with repository secrets, deployment tokens, or other sensitive credentials.
The danger is not limited to one repository. A widely reused action can propagate risk across many projects, and secrets exposed in workflow logs can be copied quickly, searched later, or reused for follow-on access. That is why supply-chain style compromises in CI/CD are so disruptive: the attacker does not need to break each target individually if they can poison a shared automation step.
How Exposure Happens in Practice
Exposure usually starts with trust in a third-party action, especially when it is referenced by tag rather than an immutable commit. If the action is altered upstream, every workflow that pulls it in may execute the new code automatically. The reviewdog compromise is a good example of why action integrity matters as much as the application code being built.
Organisations should confirm whether they use the affected action anywhere in active workflows, then check where those workflows can reach secrets, write logs, publish artifacts, or trigger downstream deployments. The practical question is not just whether the repository contains the dependency, but whether the workflow context gives that dependency access to material secrets or privileged runtime credentials. NHI breach analysis across real incidents shows how often leaked API keys, tokens, and service credentials become the first usable prize for attackers, and why secret exposure in pipelines is so valuable to them.
Detection, Review, and Containment
Detection should focus on both the vulnerable workflow path and the aftermath of secret exposure. Review build logs for unexpected secret values, unusual echo output, or any evidence that a workflow step printed variables that should never have been visible. If the action was used before it was removed, inspect whether any logs, artifacts, or job summaries may have retained exposed material.
After patching or removing the action, assume that exposed secrets may already be compromised and review adjacent systems for misuse. GitHub Actions compromises often cascade because a leaked token is enough to mint new access, pull additional secrets, or modify workflows. That is why pipeline compromise review must include downstream repositories, package registries, cloud accounts, and any automation that the leaked secret could reach.
Why This Pattern Keeps Reappearing
This vulnerability pattern is dangerous because it combines software supply-chain trust with secret handling inside ephemeral automation. Build systems often have broad permissions, and many teams still assume that a workflow log is a harmless diagnostic record. In reality, logs are part of the attack surface when a malicious or compromised action can dump secrets into them.
For that reason, the security lesson extends beyond one CVE. Any reusable CI/CD component that can read environment variables, access repository secrets, or run with publishing rights deserves the same scrutiny as production code. Where teams treat actions as harmless glue code, attackers treat them as a high-value execution path.
Risk and Threat Considerations
This vulnerability creates a direct secret-exposure risk, but the bigger threat is follow-on abuse of whatever those secrets unlock. A leaked workflow token, cloud credential, package publishing key, or service account secret can enable repository takeover, artifact tampering, credential pivoting, or lateral movement into connected systems.
Failure mechanism: Malicious code inside the action executes in a trusted pipeline context and dumps available secrets into workflow logs or other readable output, where they can be collected and reused.
Impact: Attackers may gain persistent access to source control, deployment systems, package registries, or cloud resources, and the compromise can spread through any automation that trusts those credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5, OWASP ASVS and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | CI/CD actions are software dependencies that must be secured and monitored. |
| Recommendation — Review and harden reusable build actions before allowing them in production workflows. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | The action embeds malicious code that can execute during workflows. |
| AU-2 — Event Logging | Exposed secrets can appear in workflow logs and must be controlled. | |
| Recommendation — Block and detect malicious code in pipeline inputs and automation steps. Review workflow logging so sensitive values are never written to logs. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | The vulnerability leaks secrets through logs, a logging control failure. |
| Recommendation — Prevent sensitive data from appearing in application and pipeline logs. | ||
| SLSA | Supply Chain Security | The issue is a software supply-chain compromise of a reusable build component. |
| Recommendation — Require immutable provenance and trusted sources for build dependencies. | ||
Practitioner Guidance
Why practitioners should care: Treat third-party actions as executable supply-chain dependencies, not convenience wrappers. If a workflow can see secrets, the action running inside it can potentially expose them, so the trust decision has to be explicit and reviewed.
What to watch for: Prioritise workflows that handle release secrets, deployment tokens, or organisation-level credentials, especially when they reference mutable tags or broad permissions. In practice, the safest review path is to verify the action source, constrain the workflow’s secret access, and rotate any secret that may have been visible during compromise.