Secret Exposure in tj-actions/changed-files GitHub Action

Historical catalog analysis: CISA added this entry on March 18, 2025. The entry reflects catalog information retrieved on August 31, 2026, not a snapshot archived on the inclusion date. Check current vendor guidance before acting.

What the vulnerability is

CVE-2025-30066 identifies a vulnerability (CWE-506) involving embedded malicious code within the tj-actions/changed-files GitHub Action. The flaw allows remote attackers to discover sensitive secrets by accessing GitHub Actions Workflow Logs. Reported exposed data includes, but is not limited to, private RSA keys, npm tokens, GitHub personal access tokens (PATs), and AWS access keys.

Exposure and applicability

This vulnerability affects organizations utilizing the tj-actions/changed-files action within their CI/CD pipelines. The exposure path is centered on the visibility of workflow logs; if an attacker can read these logs, they may obtain the secrets leaked by the malicious code. This is particularly critical for environments where high-privilege tokens are passed into the workflow environment.

Potential breach-prevention strategy

The reported failure involves embedded malicious code that leaks secrets into logs, which are then readable by a remote attacker. It remains unknown how the malicious code was introduced or the specific trigger conditions for the leak.

Our analysis suggests the following prioritized actions to reduce the likelihood of similar exposures:

1. Pin Actions to Specific Commit SHAs: To prevent the automatic adoption of compromised updates, use full commit hashes rather than tags or version branches. This is a preventative control against initial compromise via supply chain updates.
2. Hypothetical Scenario: A trusted tag is updated by an attacker to point to a compromised version of the code.
3. Responsible Role: CI/CD Pipeline Architect.

4. Verification: Scan .github/workflows files for the presence of commit SHAs instead of @vX.X.X tags.

5. Restrict Workflow Log Access: To prevent initial access to leaked data, restrict who can view GitHub Actions logs to only authorized personnel.

6. Hypothetical Scenario: An attacker gains read-only access to a repository and views logs containing leaked secrets.
7. Responsible Role: Repository Administrator.

8. Verification: Review repository permission settings to ensure log visibility is limited to necessary team members.

9. Implement Secret Masking and Least Privilege: To limit damage after an initial compromise, ensure that tokens provided to workflows have the minimum permissions necessary for the task.

10. Hypothetical Scenario: A leaked token has administrative rights rather than read-only rights, increasing the impact of the leak.
11. Responsible Role: DevOps/Security Engineer.
12. Verification: Audit existing workflow secrets to ensure restricted scopes are used where possible.

Actions 1 and 2 could have been feasible before this specific incident occurred. Action 3 is a continuous damage-limitation strategy. Residual risk remains if an attacker possesses valid credentials to view logs or if the malicious code bypasses standard masking mechanisms.

Remediation priorities

Defenders should prioritize the following corrective actions based on CISA and vendor guidance:
* Immediate Identification: Audit all GitHub Action workflows to determine if tj-actions/changed-files is currently in use.
* Apply Mitigations: Implement the specific mitigations provided by CISA and the vendor.
* Discontinuation: If mitigations cannot be verified or applied, discontinue the use of the product entirely to eliminate the exposure path.

How to validate remediation

Verification must go beyond a simple version check. To prove that exposure has been reduced, defenders should:
1. Verify Implementation: Confirm that the specific CISA/vendor mitigation steps have been executed across all affected repositories.
2. Log Audit: Review recent workflow logs for any evidence of leaked secrets (e.g., searching for patterns matching AWS keys or RSA headers) to determine if a compromise occurred prior to remediation.
3. Configuration Validation: Confirm that the action has either been removed or updated to a known-safe state as defined by the vendor’s instructions.

Limits and open questions

There is currently no information regarding whether this vulnerability has been used in ransomware campaigns. While applying mitigations reduces risk, residual risk remains if secrets were leaked into logs prior to the fix; those secrets must be considered compromised and rotated regardless of the current state of the GitHub Action.

Source and editorial note

CVE-2025-30066: tj-actions/changed-files GitHub Action Embedded Malicious Code Vulnerability · Source date: March 18, 2025 · Retrieved August 31, 2026.

Material facts are tied to the cited primary source. Recommendations are independent defensive analysis unless attributed to the source. Confirm consequential decisions against current authoritative guidance.

Archive date: March 21, 2025. The displayed post date is assigned three days after the source date to organize this retrospective archive; it does not mean this site published the analysis then. First published by this site: October 21, 2026 at 00:43 UTC.

Request a Vulnerability Assessment