Topic starter
02/08/2026 11:53 am
TL;DR: A compromise in tj-actions/changed-files injected code that printed API keys, tokens, and credentials into GitHub Actions build logs, with pinned tagged versions also vulnerable when tags were retargeted, according to Exaforce. The incident shows that supply chain trust, not just workflow hygiene, is the core control failure for CI/CD secrets governance.
Editorial analysis by NHI Mgmt Group, based on content published by Exaforce: “Safeguarding against Github Actions(tj-actions/changed-files) compromise”.
By the numbers:
- Since March 14, 2025, Exaforce has been helping design partners respond to the compromise.
- The compromise led to CVE-2025-30066.
Key questions
Q: What happens when a malicious GitHub Action is used in a CI/CD pipeline?
A: When a malicious action is executed inside CI/CD, it inherits the permissions and context granted to that workflow.
Q: Why do compromised workflow actions create broader risk than a single bad commit in a repository?
A: A compromised workflow action can expose any secrets passed into that workflow, especially when logs are public or broadly accessible.
Q: What are the signs that a third-party CI/CD action may be unsafe to keep using?
A: Look for tag retargeting, unexplained workflow changes, unexpected log output, secret values appearing in job logs and actions that require more permissions than the task justifies.
Practitioner guidance
- Remove untrusted third-party actions from critical workflows Inventory all repositories using external GitHub Actions and replace high-risk dependencies in release and deploy pipelines first.
- Pin external actions to immutable commit SHAs Replace version tags with commit SHAs for every third-party action, and verify that repository owners cannot silently retarget references in ways your governance process would miss.
- Review workflow token scope and secret exposure paths Apply least privilege to GITHUB_TOKEN and any reusable credentials, then check which workflows can print secrets into logs, artifacts or external monitoring streams.
Bottom line: A poisoned GitHub Action can turn a normal CI/CD job into a secret exposure event if the workflow has broad permissions and logs are accessible.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:02 pm
Supply chain trust is now an identity control problem: when a third-party action executes inside a pipeline, it inherits delegated authority over secrets, logs and downstream systems. That makes the action closer to a non-human identity than a static dependency, because its effective privilege is determined at runtime. For practitioners, the governance boundary is no longer the repository alone; it is the trust relationship between workflow, maintainer and execution context.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
A question worth separating out:
Q: How should teams respond when build logs may contain leaked secrets?
A: Treat the logs as a disclosure source, not just an investigation record. Identify every secret that may have been printed, revoke or rotate the affected credentials, review downstream systems that used them, and tighten workflow permissions so the same build path cannot expose credentials again.
👉 Read our full editorial: GitHub Actions supply chain compromise exposes secrets in build logs