Skip to content

chore(deps): bump actions/cache from 5 to 6 #119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dependabot wants to merge 1 commit into
base: main
Choose a base branch
from
Open

chore(deps): bump actions/cache from 5 to 6 #119

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/test.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ jobs:
registry-url: "https://registry.npmjs.org"

- name: Cache zstd build
uses: actions/cache@v5
uses: actions/cache@v6

@semgrep-code-mongodb semgrep-code-mongodb Bot Jul 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Semgrep identified an issue in your code:

actions/cache@v6 uses a mutable tag, so if v6 is repointed, this workflow can execute attacker-controlled code during CI.

More details about this

Cache zstd build pulls actions/cache using the mutable ref @v6, not a specific commit. If the v6 tag is ever moved to a different commit, this workflow will run that new code during host_tests, before npm run install-zstd, npm install, and npm test.

A plausible attack looks like this:

  1. An attacker gains the ability to publish a new commit under the actions/cache repository and repoints the v6 tag to it.
  2. Your workflow starts on push, pull_request, or workflow_dispatch and reaches uses: actions/cache@v6 in the Cache zstd build step.
  3. GitHub downloads and executes the attacker's version of actions/cache because the workflow trusts @v6.
  4. That malicious action can read this job's workspace, inspect files used in path: deps and key: zstd-deps-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles(...) }}, and use the job's token or other available secrets to send repository data to an external server.
  5. Because this happens before later build and test commands, the attacker-controlled action runs inside your CI for every matching job without changing this repository's code.

This is a supply-chain risk in the exact uses: actions/cache@v6 line because the workflow follows a tag that can be silently changed later.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference actions/cache@v6 with a full 40-character commit SHA for the exact actions/cache release you want to use.
  2. Keep the version as a comment next to the SHA so the workflow stays readable, for example: uses: actions/cache@<full-40-char-sha> # v6.x.x.
  3. Choose the SHA from the official actions/cache release you intend to trust, and make sure it is the commit for that release tag rather than a branch or short tag. Pinning to a commit SHA prevents the action owner from silently changing what runs under the same tag.
  4. Update only the uses value for this step; the existing with: settings such as path: and key: can stay as they are.

Alternatively, if you need to confirm the correct pinned revision before editing, look up the actions/cache release page and copy the full commit SHA associated with the v6 release you want to keep using.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

  • /fp <comment> for false positive
  • /ar <comment> for acceptable risk
  • /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

  • Fix the code
  • Reply /fp $reason (if security gap doesn’t exist)
  • Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
  • Reply /other $reason (e.g., test-only)

You can view more details about this finding in the Semgrep AppSec Platform.

with:
path: deps
key: zstd-deps-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('package.json', 'package-lock.json', 'etc/install-zstd.sh') }}
Expand Down
Loading