chore(deps): bump docker/login-action from 4.5.1 to 4.6.0 - #94
Conversation
Bumps [docker/login-action](https://github.com/docker/login-action) from 4.5.1 to 4.6.0. - [Release notes](https://github.com/docker/login-action/releases) - [Commits](docker/login-action@v4.5.1...v4.6.0) --- updated-dependencies: - dependency-name: docker/login-action dependency-version: 4.6.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
dependabot
Bot
added
dependencies
![semgrep-code-wireapp[bot]](https://avatars.githubusercontent.com/u/16047324?s=60&v=4){kind=small}
|
|
||
| - name: Login to Quay.io | ||
| uses: docker/login-action@v4.5.1 | ||
| uses: docker/login-action@v4.6.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
The docker/login-action@v4.6.0 tag can be silently repointed, causing the workflow to run attacker-controlled code with Quay credentials and potentially tamper with published images.
More details about this
docker/login-action@v4.6.0 uses a version tag rather than an immutable commit. The deploy-staging job runs this step on pushes to main and passes ${{ secrets.QUAY_USERNAME }} and ${{ secrets.QUAY_ROBOT_TOKEN }} to the action. If the docker/login-action owner—or an account that compromises the repository—moves the v4.6.0 tag, a later workflow run can execute attacker-controlled action code instead of the intended login implementation.
A plausible attack would be:
- The attacker repoints
v4.6.0to a malicious commit. - A developer pushes to
main, triggeringdeploy-staging. - The malicious
docker/login-actionruns with the Quay credentials supplied throughusernameandpassword, then sendsQUAY_ROBOT_TOKENto an attacker-controlled endpoint or uses it to alter images inquay.io/wire/poll-app. - The workflow continues to
Build and push, allowing the attacker to tamper with the image published bydocker/build-push-actionor use the stolen credentials outside this workflow.
Because the reference can change without any workflow-file change, a previously reviewed workflow can begin executing different code on a future main push.
To resolve this comment:
✨ Commit fix suggestion
| uses: docker/login-action@v4.6.0 | |
| uses: docker/login-action@<VERIFIED_VALUE_REQUIRED> |
View step-by-step instructions
- Replace the mutable version tag with the full 40-character commit SHA for the trusted
docker/login-actionrelease corresponding tov4.6.0:uses: docker/login-action@<40-character-commit-sha>. - Verify that the SHA belongs to the intended release in the official
docker/login-actionrepository before using it. Do not use@v4,@v4.6.0, or a shortened SHA. - Keep the existing
registry,username, andpasswordinputs unchanged. A full commit SHA prevents the action code from changing if the tag is later 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.
You can view more details about this finding in the Semgrep AppSec Platform.
1 participant
Bumps docker/login-action from 4.5.1 to 4.6.0.
Release notes
Sourced from docker/login-action's releases.
Commits
dbcb813Merge pull request #1051 from docker/dependabot/npm_and_yarn/aws-sdk-dependen...5bcb015[dependabot skip] chore: update generated contentb30b2f2build(deps): bump the aws-sdk-dependencies group across 1 directory with 2 up...9087f1eMerge pull request #1057 from docker/dependabot/npm_and_yarn/js-yaml-5.2.20009830[dependabot skip] chore: update generated content2325523build(deps): bump js-yaml from 5.2.1 to 5.2.24ec1d4aMerge pull request #1056 from docker/dependabot/npm_and_yarn/postcss-8.5.225fc99baMerge pull request #1053 from docker/dependabot/github_actions/aws-actions/co...e512bd5Merge pull request #1052 from docker/dependabot/github_actions/codeql-actions...a146c91Merge pull request #1059 from crazy-max/harden-buildx-scope-pathsDependabot 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)