chore(deps): Bump actions/setup-java from 5 to 5.6.0 - #127
Conversation
Bumps [actions/setup-java](https://github.com/actions/setup-java) from 5 to 5.6.0. - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@v5...v5.6.0) --- updated-dependencies: - dependency-name: actions/setup-java dependency-version: 5.6.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
![semgrep-code-wireapp[bot]](https://avatars.githubusercontent.com/u/16047324?s=60&v=4){kind=small}
| steps: | ||
| - uses: actions/checkout@v7 | ||
| - uses: actions/setup-java@v5 | ||
| - uses: actions/setup-java@v5.6.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
GitHub Actions step uses a mutable tag (v5.6.0) that can be repointed by the action owner to inject malicious code into your workflow. Pin to a full commit SHA instead to prevent supply-chain attacks.
More details about this
The actions/setup-java@v5.6.0 step uses a mutable version tag (v5.6.0) instead of pinning to a specific commit SHA. Even though this looks like a precise version, GitHub Actions tags can be moved or retagged by the action owner after you've written your workflow.
Here's how an attacker could exploit this:
- Compromise the action repository: An attacker gains control of the
actions/setup-javarepository (through account compromise, supply-chain attack, etc.) - Retag the version: The attacker moves the
v5.6.0tag to point to their malicious commit - Inject malicious code: Your workflow runs their compromised version of
setup-javawithout any indication that something changed - Exfiltrate secrets or modify build artifacts: The malicious
setup-javastep now has access to your workflow's environment variables, secrets, and can modify what gets built or published
This exact scenario happened with real GitHub Actions: the trivy-action and kics-github-action were compromised when maintainers' accounts were taken over, and mutable tag references meant workflows silently pulled compromised versions without any notification.
Pinning to a full 40-character commit SHA (like actions/setup-java@8ade135a41bc03ea155e62e844d188df1ea18608) prevents the tag from being moved and ensures your workflow always uses the exact code you verified.
To resolve this comment:
✨ Commit fix suggestion
| - uses: actions/setup-java@v5.6.0 | |
| # TODO: Replace the placeholder SHA below with the official 40-character commit SHA for actions/setup-java v5.6.0 | |
| # from the upstream release/tag page before merging. GitHub Actions should be pinned to a full commit SHA. | |
| - uses: actions/setup-java@<40-character-commit-sha-for-v5.6.0> | |
| with: | |
| distribution: 'zulu' | |
| java-version: '21' |
View step-by-step instructions
-
Replace the mutable action reference with a full 40-character commit SHA for the same
actions/setup-javarelease.
Changeuses: actions/setup-java@v5.6.0touses: actions/setup-java@<40-character-commit-sha-for-v5.6.0>. -
Keep the rest of the step unchanged, including the
with:block fordistributionandjava-version.
Pinning to a commit SHA prevents the action owner from silently changing what runs for that reference. -
Verify the SHA from the official
actions/setup-javarepository release or tag page before updating the workflow, so the pinned commit matches the version you intended to use.
💬 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.
You can view more details about this finding in the Semgrep AppSec Platform.
1 participant
Bumps actions/setup-java from 5 to 5.6.0.
Release notes
Sourced from actions/setup-java's releases.
... (truncated)
Commits
c5f2f2eBump github/codeql-action from 3 to 4 (#1069)623c707chore: enforce pre-PR validation (aggregate scripts, git hooks, PR checklist)...1bcf9fbdist: Address Copilot review suggestions from PR #1042 (GraalVM Community) (#...Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)