Skip to content

build(deps): bump actions/stale from 10 to 11 #4694

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

Merged
apix-bot merged 1 commit into from
Aug 6, 2026
+1 −1
Merged

build(deps): bump actions/stale from 10 to 11 #4694

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
2 changes: 1 addition & 1 deletion .github/workflows/stale.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ jobs:
- uses: GitHubSecurityLab/actions-permissions/monitor@v1
with:
config: ${{ vars.PERMISSIONS_CONFIG }}
- uses: actions/stale@v10
- uses: actions/stale@v11

@semgrep-code-mongodb semgrep-code-mongodb Bot Aug 4, 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:

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
  1. Replace the mutable tag in the uses line with a full 40-character commit SHA for the same actions/stale release.
  2. Keep the current version as an inline comment so the pinned SHA is easier to track later, for example change uses: actions/stale@v11 to uses: actions/stale@<full-40-character-commit-sha> # v11.
  3. Get the correct SHA from the actions/stale release or tag page and make sure it is the commit that backs v11. 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.

id: stale
with:
stale-issue-message: 'This issue has gone 30 days without any activity and meets the project’s definition of "stale". This will be auto-closed if there is no new activity over the next 30 days. If the issue is still relevant and active, you can simply comment with a "bump" to keep it open, or add the label "not_stale". Thanks for keeping our repository healthy!'
Expand Down
Loading