build(deps): bump actions/stale from 10 to 11 - #4694
Conversation
Bumps [actions/stale](https://github.com/actions/stale) from 10 to 11. - [Release notes](https://github.com/actions/stale/releases) - [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md) - [Commits](actions/stale@v10...v11) --- updated-dependencies: - dependency-name: actions/stale dependency-version: '11' 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
|
The ticket CLOUDP-430840 was created for internal tracking. Note: Jira ticket will be closed automatically when this PR is merged. |
![semgrep-code-mongodb[bot]](https://avatars.githubusercontent.com/u/45120?s=60&v=4){kind=small}
| with: | ||
| config: ${{ vars.PERMISSIONS_CONFIG }} | ||
| - uses: actions/stale@v10 | ||
| - uses: actions/stale@v11 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
actions/stale@v11 uses a movable tag, so a repointed tag would run new code in this scheduled job with permission to modify issues and pull requests.
More details about this
actions/stale is pulled with the mutable tag @v11, so this scheduled workflow will run whatever code the actions/stale maintainers later point v11 to. Because this job runs every day and has issues: write and pull-requests: write, a repointed tag could automatically post attacker-controlled comments, add the stale label, or close issues and PRs in this repository.
A plausible abuse path is: 1) an attacker compromises the actions/stale release process or maintainer account for actions/stale; 2) they move the v11 tag to a new commit containing malicious action code; 3) at the next schedule run, GitHub resolves uses: actions/stale@v11 to that attacker-chosen commit; 4) that code executes in the stale job with this repository's token permissions; 5) it can then use those permissions to modify issue and PR state, for example mass-comment on sensitive threads, apply stale to active PRs, or close discussions to disrupt maintainers. The same risk applies on manual workflow_dispatch runs, because the workflow always trusts the current target of @v11 instead of a fixed commit.
To resolve this comment:
✨ Commit fix suggestion
- Replace the mutable tag in the
usesline with a full 40-character commit SHA for the sameactions/stalerelease. - Keep the current version as an inline comment so the pinned SHA is easier to track later, for example change
uses: actions/stale@v11touses: actions/stale@<full-40-character-commit-sha> # v11. - Get the correct SHA from the
actions/stalerelease or tag page and make sure it is the commit that backsv11. Pinning to a commit SHA prevents the action owner from silently changing what runs under the same tag name.
Alternatively, if you need to stay on a specific patch release, pin to the full SHA for that exact release tag instead of the major tag, for example # v11.x.y.
💬 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.
|
coverage: 64.335%. remained the same — dependabot/github_actions/master/actions/stale-11 into master |
2 participants
Bumps actions/stale from 10 to 11.
Release notes
Sourced from actions/stale's releases.
... (truncated)
Changelog
Sourced from actions/stale's changelog.
... (truncated)
Commits
4391f3dFix 24 high severity vulnerabilities by overriding brace-expansion to 5.0.8 (...eaf9131refactor: update imports to use ES module syntax and improve test structure (...Dependabot 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)