Yes. CISA added CVE-2025-30066 to its Known Exploited Vulnerabilities catalogue on 18 March 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. tj-actions/changed-files GitHub Action contains an embedded malicious code vulnerability that allows a remote attacker to discover secrets by reading Github Actions Workflow Logs.
What “being exploited in the wild” means for this CVE
This question is really about exploitation status, not just technical severity. For CVE-2025-30066, the key signal is that CISA placed it in the KEV catalogue, which means defenders should treat it as actively exploited and operationally urgent. In practice, that shifts the response from routine vulnerability tracking to immediate exposure confirmation, containment, and compromise review.
Because the issue affects a GitHub Action, the practical question is whether any workflow still references a vulnerable or compromised version of the action, and whether those runs had access to secrets, tokens, or other sensitive workflow material. If a workflow executed the action before containment, logs and artifacts may need review for evidence of secret disclosure or follow-on abuse.
Where the exposure usually sits in GitHub Actions
The main security boundary is not the repository alone, but the workflow execution path, the permissions granted to the job, and what the action could read during runtime. A compromised action can turn ordinary CI/CD logging into a secrets leak channel, especially when workflows print environment values, masked values are bypassed, or tokens are available during the job.
That is why a supply-chain issue in a GitHub Action can become a secrets problem very quickly. The most important downstream question is whether the workflow had access to repository secrets, cloud credentials, package publish tokens, or GitHub-provided tokens with enough scope to move laterally or tamper with releases. The linked GitHub and GitHub Actions Security Guide covers the hardening choices that reduce that blast radius.
For broader context on how a poisoned action can leak CI/CD material, the tj-actions/changed-files compromise 2025 shows the kind of operational failure pattern defenders should be looking for after exposure. For teams building a stronger baseline around workflow identity and token handling, the CI/CD Pipeline Identity Security Guide is the more general control reference.
How to respond if your workflows may have been affected
Start by identifying every repository and workflow that calls the action, directly or through a reusable workflow or composite action. Then verify whether those runs occurred before the malicious code was removed, whether logs were retained, and whether any secrets were available at runtime. If the action had access to anything valuable, assume the exposure may extend beyond the single workflow run.
If patching or workflow cleanup cannot happen immediately, the safest interim step is to disable the affected workflow path, rotate any secrets that could have been exposed, and review recent job logs for suspicious output or exfiltration indicators. For teams that need a formal triage sequence, the Zero-Day and Exploited Vulnerabilities Guide is useful because it ties KEV-based urgency to emergency mitigation and post-patch hunting.
Also confirm whether the compromise could have crossed project boundaries. In CI/CD environments, a single compromised action can affect multiple repositories, release pipelines, and publishing credentials if they share the same runner trust model or secret store. The right recovery question is not only “is the vulnerable action still installed?” but also “what else could it have touched before removal?”
Risk and Threat Considerations
Actively exploited CI/CD supply-chain flaws are dangerous because they combine silent execution with privileged workflow access. A malicious action can read secrets during a legitimate build, hide inside normal job output, and create downstream compromise opportunities long after the vulnerable code is removed.
Failure mechanism: The action runs inside a trusted pipeline context and can inspect workflow-visible data, including tokens and secrets that were never meant to leave the job boundary. If the workflow logs or artifacts preserve that output, the attacker gains a durable copy of sensitive material.
Impact: Secret disclosure can lead to repository takeover, package publication abuse, cloud access, or further supply-chain compromise, depending on what the workflow was allowed to touch. For a GitHub Actions issue, the practical damage is often broader than the single repository because the same automation patterns are reused across projects.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerability Identification | Active exploitation status requires identifying the vulnerable workflow and its exposure. |
| PR.AA-05 — Identity Management, Authentication, and Access Enforcement | GitHub Actions risk depends on workflow token and secret access control. | |
| DE.CM-08 — Vulnerability Scans Are Performed | KEV-listed exploitation warrants focused verification of where the vulnerable action is still used. | |
| Recommendation — Identify affected workflows and rank them for immediate containment and recovery. Restrict workflow token scope and secret access to the minimum needed. Continuously verify whether the vulnerable action remains present in active workflows. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Workflow logs are central evidence for secrets disclosure and compromise review. |
| IA-5 — Authenticator Management | The issue can expose CI/CD credentials, tokens, and related secret material. | |
| SI-3 — Malicious Code Protection | The CVE involves embedded malicious code in a trusted automation component. | |
| Recommendation — Review CI/CD logs and job records for secret leakage indicators. Rotate exposed tokens and credentials immediately after suspected disclosure. Block or remove compromised automation components before they execute again. | ||
| CIS Controls v8 | 5 — Account Management | CI/CD exposure often affects accounts and tokens embedded in automation workflows. |
| 16 — Application Software Security | A compromised GitHub Action is a software supply-chain and build-path security issue. | |
| Recommendation — Inventory and remove stale workflow credentials and unnecessary privileges. Validate third-party build components before they are allowed in pipelines. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | The vulnerability abuses workflow logs to expose secrets. |
| Recommendation — Protect logs from revealing credentials and review them for sensitive output. | ||
| SLSA | Build provenance | A poisoned action undermines build integrity and trusted pipeline provenance. |
| Recommendation — Require trusted provenance for build-time dependencies and actions. | ||
Practitioner Guidance
What to verify: Confirm whether any workflow used the affected action before remediation, whether the job had access to high-value secrets, and whether logs or artifacts were retained. If the action ever executed in a release, signing, deployment, or publishing workflow, treat the blast radius as higher than a routine build job.
Decision rule: If you cannot prove the action had no access to secrets, rotate the exposed credentials first and investigate second. If you can prove that the workflow was isolated and secret-free, you still need to verify that no cached logs, artifacts, or downstream jobs preserved the disclosure path.
Practitioner takeaway: For exploited CI/CD supply-chain issues, the decisive question is not whether the package is now fixed, but whether the workflow’s trust boundary was already crossed and secrets may already have left the build context.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2025-30066 (tj-actions/changed-files GitHub Action Embedded Malicious Code)?
- CVE-2025-30066 (tj-actions/changed-files GitHub Action Embedded Malicious Code)
- Is CVE-2025-30154 (reviewdog/action-setup GitHub Action Embedded Malicious Code) being exploited in the wild?
- Is CVE-2025-54313 (Prettier eslint-config-prettier Embedded Malicious Code) being exploited in the wild?