# tj-actions compromise: CI logs can become a secret-exfiltration channel

Canonical: https://www.web3sec.news/blog/tj-actions-ci-secret-exposure
Author: Raiders (https://www.web3sec.news/about)
Format: postmortem
Topic: Supply chain
Published: 2026-11-08
Updated: 2026-11-08
Incident date: 2025-03-14

CVE-2025-30066 demonstrates why action versions, workflow permissions and build logs belong in one threat model.

### Diagram: Trust the release path, not only the source.

Protect the chain from reviewed change to the artifact receiving traffic.

![Protected source enters a least-privilege release workflow, produces a digest-identified artifact, and reaches production only after artifact verification. Untrusted pull requests use isolated checks without release credentials or write access.](https://www.web3sec.news/diagrams/software-release-trust.svg)

[Full-size SVG](https://www.web3sec.news/diagrams/software-release-trust.svg) · [PNG download](https://www.web3sec.news/diagrams/software-release-trust.png)

Original explanatory control model; not a reconstruction of private incident evidence.

## What the CVE record establishes

The CVE-2025-30066 record describes malicious changes to tj-actions/changed-files tags during 14–15 March 2025. Affected tags were redirected to a commit containing code that exposed secrets through workflow logs. The record identifies releases before version 46 in its affected range.

A workflow does not have to send a secret to a suspicious external host to expose it. When a build publishes sensitive values in a readable log, the normal CI platform itself becomes the delivery mechanism.

## Pinning is a review mechanism

Our analysis: use full commit hashes for third-party actions and review the changes when those hashes move. A hash fixes the selected code; it does not prove that code is safe. Check an action’s own dependencies and scripts, as well as the top-level workflow reference.

Keep validation jobs free of production credentials. Set default token permissions to read-only and grant specific writes only where needed. Give deployment its own restricted environment and obtain short-lived, scoped credentials where supported. Untrusted pull-request content must not flow into a privileged job or interpolated shell program.

## Respond to the run, not just the repository file

If an affected action executed, establish which revision ran, which secrets were available and who could access the resulting logs. Preserve the necessary evidence in a restricted location, remove exposed public artifacts and rotate the affected credentials. Updating the workflow cannot retract a secret that has already been copied.

Make a recurring inventory of external actions and their permission needs. Remove workflow steps whose output is unused; each one adds code that can execute in the runner’s security context.

## Controls to take away

- Pin reviewed action revisions and restrict job permissions.
- Keep production secrets out of ordinary validation jobs.
- Rotate exposed credentials even after removing malicious code.

## Sources & further reading

- [CVE record: CVE-2025-30066](https://www.cve.org/CVERecord?id=CVE-2025-30066)

Incident facts are attributed to the linked reports. Recommendations are Web3Sec's analysis.

[Research methodology](https://www.web3sec.news/methodology) · [Editorial policy](https://www.web3sec.news/editorial-policy) · [Send a correction](https://www.web3sec.news/contact)