Skip to content

chore(deps): bump actions/setup-java from 5.6.0 to 6.0.0 #95

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

Merged
bbaarriiss merged 1 commit into from
Sep 1, 2026
Merged

chore(deps): bump actions/setup-java from 5.6.0 to 6.0.0 #95

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/pull-request.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ jobs:
runs-on: ubuntu-22.04
steps:
- uses: actions/checkout@v7
- uses: actions/setup-java@v5.6.0
- uses: actions/setup-java@v6.0.0

@semgrep-code-wireapp semgrep-code-wireapp Bot Sep 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:

The build runs actions/setup-java from the mutable v6.0.0 tag. If that tag is repointed, a future pull-request workflow can execute attacker-controlled code with access to the runner and any available workflow credentials.

More details about this

actions/setup-java@v6.0.0 selects a mutable release tag rather than an immutable commit. The action owner can move v6.0.0 to a different commit without changing this workflow, so a future run could execute attacker-controlled code before ./gradlew ktlintCheck, ./gradlew detekt, and ./gradlew build --info run.

A plausible attack is:

  1. An attacker compromises the actions/setup-java release process or gains control of the v6.0.0 tag.
  2. They repoint v6.0.0 to code that runs during the actions/setup-java step and reads the checkout, environment, and available GitHub Actions credentials.
  3. When this Build workflow runs for a pull request, the malicious step can alter files or Gradle configuration before the ./gradlew commands execute, capture accessible GITHUB_TOKEN or repository secrets, and send them to an attacker-controlled server.
  4. The workflow still appears to perform the normal Java setup and build, making the compromise difficult to notice. The same workflow also uses mutable references for actions/checkout@v7 and actions/upload-artifact@v7, creating additional moving trust dependencies.

To resolve this comment:

✨ Commit fix suggestion

Suggested change
- uses: actions/setup-java@v6.0.0
- uses: actions/setup-java@<VERIFIED_VALUE_REQUIRED>
View step-by-step instructions
  1. Replace the mutable v6.0.0 reference with the full 40-character commit SHA that corresponds to the actions/setup-java v6.0.0 release: uses: actions/setup-java@<40-character-commit-SHA>.
  2. Keep the existing with configuration unchanged. A commit SHA cannot be silently moved to different code, unlike a version tag or branch name.
  3. Apply the same SHA-pinning format to the other third-party actions in this workflow, such as actions/checkout and actions/upload-artifact, if they are also not pinned to full 40-character commit SHAs.
💬 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.

with:
distribution: 'zulu'
java-version: '21'
Expand Down