Is CVE-2025-30154 (reviewdog/action-setup GitHub Action Embedded Malicious Code) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

Yes. CISA added CVE-2025-30154 to its Known Exploited Vulnerabilities catalogue on 24 March 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. reviewdog action-setup GitHub Action contains an embedded malicious code vulnerability that dumps exposed secrets to Github Actions Workflow Logs. Any organisation running the affected product should treat remediation as urgent.

What makes this a real in-the-wild exploitation case?

CISA’s KEV listing is the key signal here: it means the issue is not just theoretically dangerous, but has reliable evidence of active exploitation. For teams that run GitHub Actions, the practical question is whether any workflow, repository, or build pipeline still references the affected action, because embedded malicious code can expose secrets immediately during routine execution.

That is why the risk is operational as much as technical. If the action is still present in a workflow, the compromise path can be triggered by normal CI activity, and the exposure happens inside workflow logs rather than through a visible application failure.

For background on why this class of issue is treated as urgent, see Zero-Day and Exploited Vulnerabilities Guide.

How should teams confirm exposure and scope?

Start by identifying every repository, reusable workflow, and action reference that could invoke reviewdog/action-setup. Treat transitive use as part of scope too, because a compromised or pinned workflow can still execute the action even when it is not obvious in the primary repository file. If you rely on shared templates, check the parent workflow sources, not just the consuming repos.

Then determine what secrets the workflow could access at runtime. In GitHub Actions, that includes repository secrets, environment secrets, tokens granted to the job, and any credentials passed through composite or reusable workflows. If the workflow had access to deployment credentials, the exposure is broader than log leakage alone.

The most useful operational reference point is the workflow boundary itself, so review your GitHub hardening against GitHub and GitHub Actions Security Guide.

What should happen when patching or removal cannot wait?

Remove or disable the affected action first, then rotate any secrets that may have been available to the workflow. If the workflow handled production deployment or package-publishing credentials, assume those values may already be exposed and treat them as compromised until proven otherwise. The practical response is not limited to source-code cleanup, it also includes revoking tokens, reissuing secrets, and checking whether dependent automation still trusts the old values.

After containment, review logs and recent workflow runs for unexpected secret output, unusual job execution, or modifications that appeared before the alert. Because the malicious behavior is embedded in the action itself, you should not rely on a clean build result as proof that nothing was exposed.

For teams formalizing CI/CD controls, the right next step is to align workflow identity, token scope, and artifact trust with the CI/CD Pipeline Identity Security Guide.

Risk and Threat Considerations

This type of compromise is especially dangerous because the attacker does not need to break the application to reach sensitive material. The malicious code runs where secrets are already in scope, so the main failure mode is secret exposure through ordinary pipeline execution and log collection.

Failure mechanism: The action executes embedded malicious code during a trusted workflow step, dumps exposed secrets into logs, and may leave little obvious functional disruption, which delays detection.

Impact: Exposed CI/CD secrets can enable repository takeover, package-publishing abuse, deployment compromise, or further supply-chain attacks if the leaked credentials are still valid.

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 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-16 — Application Software Security	GitHub Actions workflows are software supply-chain code paths that need secure review and hardening.
Recommendation — Review and harden workflow code paths that can expose secrets or execute untrusted action code.
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	The issue is embedded malicious code in a trusted action, which is an integrity failure.
	IA-5 — Authenticator Management	The vulnerability can expose workflow secrets and tokens that must be rotated quickly.
	AU-6 — Audit Record Review, Analysis, and Reporting	Workflow logs are the exposure channel, so log review is central to detection and response.
Recommendation — Verify workflow and action integrity before allowing trusted pipeline execution. Rotate exposed secrets and invalidate compromised authenticators immediately. Review CI/CD audit and workflow logs for secret exposure and suspicious execution.
OWASP ASVS	V16 — Security Logging and Error Handling	The issue is discovered and investigated through what the workflow logs reveal.
Recommendation — Ensure logs do not disclose secrets and can support incident investigation.

Practitioner Guidance

What to prioritise: Rotate any secret that could have been available to the workflow before spending time on post-incident tuning. If the workflow touched release, signing, or deployment credentials, treat the incident as a trust-reset event, not just a code-removal task.

What to verify: Confirm that the action is absent from active workflows, that any cached or inherited workflow paths are also clean, and that secret values have actually been replaced rather than merely marked for future rotation. Validate recent runs for log leakage, not just current repository state.

Practitioner takeaway: In a KEV-listed CI/CD compromise, the correct posture is to assume exposure happened at execution time and prove otherwise through rotation, log review, and workflow inventory, not through trust in the build passing.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org