@dagecko This looks interesting! Do you have another link for the incident report? The one you shared returns a 404 not found. I've also looked at the https://github.com/tj-actions/changed-files/ repo, and there don't seem to be any pinned issues nor security advisories that would highlight this.

I have preemptively disabled all github actions until this issue is properly investigated.

Hey @ItsIgnacioPortal, thanks for looking into this. The broken link was from an earlier version of the PR template, apologies about that.

Here's the research doc: https://www.vigilantdefense.com/research/github-top-50k-repos-cicd-security-scan

For the tj-actions incident specifically, here are some good references:

• https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-attack-and-its-impact
• https://www.wiz.io/blog/new-github-action-supply-chain-attack-reviewdog-action-setup

The tj-actions/changed-files repo was cleaned up after the incident, which is why you won't find pinned issues or advisories there anymore. The attack compromised the action by force-pushing a malicious commit to the mutable version tag, which meant every repo referencing it by tag (instead of SHA) executed attacker code in their CI.

Also, we had a fork issue that closed the original PR (#1296). This one (#1297) is the resubmission with the same fixes. Sorry for the noise.

@ItsIgnacioPortal I really appreciate you taking this seriously. You'd be surprised how many people brush it off. It's been a long day of trying to get these fixed across projects, so it's refreshing to see someone act on it.

Here's a full breakdown of what we found and why it matters for SecLists specifically:

Finding 1: RGS-008 (High) - Secrets Directly Interpolated in run Blocks

Files: readme-updater.yml, remote-wordlists-updater.yml

These workflows use ${{ secrets.GITHUB_TOKEN }} directly inside run: blocks. GitHub Actions expressions get interpolated into the shell script before the shell sees them, which means the token value is baked into the script source code. If an attacker can influence the shell context (through another vulnerability, a compromised dependency, or log exposure), the token is right there in plaintext.

The fix moves the secret into an env: mapping so it's passed as a standard environment variable ($GITHUB_TOKEN) instead. Same behavior, but the token is no longer embedded in the script source. It's a one-line structural change.

Finding 2: RGS-007 (Medium) - Unpinned Third-Party Actions

Files: 6 wordlist-updater_*.yml workflows

All six reference ad-m/github-push-action@master. The @master tag is mutable, meaning the owner of that action (or anyone who compromises their repo) can force-push master to point at a malicious commit. Every workflow referencing @master would then execute that code with whatever permissions the job has, including your GITHUB_TOKEN with write access to SecLists.

This is exactly how the tj-actions/changed-files attack worked. The attacker force-pushed the version tag to a malicious commit, and every repo using that action executed attacker code silently.

The fix pins each action to its full 40-character commit SHA. The original version tag is preserved as a comment so you can still see what version it corresponds to. If ad-m/github-push-action is ever compromised, the pinned SHA won't resolve to the malicious commit.

What could happen if left unfixed:

SecLists is one of the most widely used security testing resources. If an attacker compromises ad-m/github-push-action, they could use your CI pipeline to push malicious content directly into the SecLists repo (since these workflows have write access). That means poisoned wordlists, payloads, or discovery lists distributed to thousands of security professionals who trust this repo. The supply chain impact would be significant.

The fixes in this PR are mechanical and preserve all existing behavior. You can review every change in the diff. Nothing changes functionally, it just closes the door on these attack vectors.

Full details on the RGS classification system: https://github.com/Vigilant-LLC/runner-guard/tree/main/rules

Happy to answer anything else.

- Chris