Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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/release-on-merge.yml
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ jobs:
- uses: pnpm/action-setup@v5
with:
version: 7.6.0
- uses: actions/setup-node@v6
- uses: actions/setup-node@v7

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:

GitHub Actions step uses mutable version tag v7 which can be repointed by the action owner to inject malicious code into your workflow. Pin to a full commit SHA instead.

More details about this

The step uses: actions/setup-node@v7 references the action using a mutable version tag (v7) instead of pinning to a specific commit SHA. Version tags can be moved or repointed by the action owner after release, allowing them to silently inject malicious code into your workflow.

Here's how an attacker could exploit this:

  1. Compromise the action repository: An attacker gains control of the actions/setup-node repository (via credential theft, internal access, or social engineering).
  2. Repoint the v7 tag: The attacker moves the v7 tag to a malicious commit they've created that contains backdoored Node.js setup logic.
  3. Your workflow pulls the malicious version: Next time your CI/CD pipeline runs, actions/setup-node@v7 resolves to the attacker's malicious commit instead of the legitimate one.
  4. Execute payload: The backdoor code runs with full access to your repository secrets (GITHUB_TOKEN), environment variables, and build artifacts. The attacker can steal credentials, modify your package contents, or compromise downstream users.

This same attack vector was used in the real-world compromises of trivy-action and kics-github-action, where attackers gained the ability to exfiltrate credentials and manipulate build outputs.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable GitHub Action reference with a full 40-character commit SHA instead of the v7 tag.
    Change uses: actions/setup-node@v7 to uses: actions/setup-node@<full-commit-sha>.

  2. Resolve the SHA from the exact action version you intend to trust.
    For example, open the actions/setup-node release or tag page, find the commit behind v7, and copy the full SHA rather than a branch or tag name.

  3. Keep the existing with: block unchanged after pinning the action.
    The step should look like - uses: actions/setup-node@8ade135a41bc03ea155e62e844d188df1ea18608 followed by the current node-version and cache settings. Pinning to a commit SHA prevents the action owner from silently moving the version reference later.

💬 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.

Need help? Review go/semgrep-playbook or Reach out in #security-vulnerabilities on Slack.

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

with:
node-version: '16'
cache: 'pnpm'
Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/test-on-pull-request.yml
Original file line number Diff line number Diff line change
Expand Up @@ -13,7 +13,7 @@ jobs:
- uses: pnpm/action-setup@v5
with:
version: 7.6.0
- uses: actions/setup-node@v6
- uses: actions/setup-node@v7

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:

GitHub Actions step uses mutable tag v7 which can be silently repointed by the action owner, enabling supply-chain attacks through malicious code injection into CI/CD pipelines.

More details about this

The workflow step actions/setup-node@v7 uses a mutable version tag (v7) instead of a pinned commit SHA. This allows the action owner to silently update what code runs in your CI/CD pipeline without your knowledge.

Here's how an attacker could exploit this:

  1. Compromise the action repository: An attacker gains access to the actions/setup-node repository on GitHub.
  2. Repoint the tag: They force-push to the v7 tag, pointing it to a malicious commit that includes backdoored Node.js setup code or credentials theft.
  3. Automatic execution: The next time your workflow runs (on any pull request), GitHub automatically pulls the latest commit at v7, which is now the attacker's malicious code.
  4. Silent compromise: Your node-version and cache settings execute against the attacker's modified action, potentially exposing secrets in ${{ secrets }} or injecting malware into your build artifacts.

This mirrors real supply-chain attacks like the Trivy and KICS GitHub Action compromises, where legitimate actions were weaponized through tag manipulation.

To prevent this, replace the mutable tag with a full 40-character commit SHA so your workflow always runs the exact same code.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference actions/setup-node@v7 with a full 40-character commit SHA for the exact release you want to keep using, for example uses: actions/setup-node@<full-commit-sha>.
  2. Keep the existing with: block unchanged so the workflow behavior stays the same, for example node-version: '16' and cache: 'pnpm' do not need to change.
  3. Get the correct SHA from the actions/setup-node release you intend to use, then paste that SHA directly into the uses: line instead of the version tag. Pinning to a commit SHA prevents the action owner from moving v7 to different code later.

Alternatively, if you need easier version updates, pin to the commit SHA that corresponds to the current v7 release and track upgrades separately by updating that SHA when you intentionally adopt a newer release.

💬 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.

Need help? Review go/semgrep-playbook or Reach out in #security-vulnerabilities on Slack.

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

with:
node-version: '16'
cache: 'pnpm'
Expand Down
Loading