Skip to content

Bump actions/stale from 10 to 11 #35

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

Bump actions/stale from 10 to 11 #35

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 @@ -14,7 +14,7 @@ jobs:
issues: write
pull-requests: write
steps:
- uses: actions/stale@v10
- uses: actions/stale@v11

@semgrep-code-mongodb semgrep-code-mongodb Bot Aug 3, 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 repointing v11 could make this scheduled job run attacker-controlled code with issue and PR write access.

More details about this

actions/stale@v11 is referenced by a movable tag, not an immutable commit. If the v11 tag is ever repointed, this scheduled workflow would start running different code every day with issues: write and pull-requests: write permissions.

A plausible attack looks like this:

  1. An attacker compromises the actions/stale action or gains permission to retag v11.
  2. They move v11 to a malicious commit while keeping the same uses: actions/stale@v11 line in your workflow.
  3. On the next nightly run (cron: '0 0 * * *') or manual run (workflow_dispatch), GitHub fetches that new code because the workflow trusts the v11 tag name.
  4. The malicious action then runs inside this stale job with write access to issues and pull-requests.
  5. Using those granted permissions, it could mass-edit issues, auto-close legitimate reports, post misleading comments, or modify PR discussions to hide attacker activity.

Because the reference is mutable, the behavior of this job can change without any change in your repository.

To resolve this comment:

✨ Commit fix suggestion

  1. Replace the mutable tag in the workflow step with a full 40-character commit SHA so the action cannot change without an explicit update.
    Change uses: actions/stale@v11 to uses: actions/stale@<full-40-char-commit-sha> # v11.

  2. Resolve the SHA from the actions/stale repository by opening the v11 release or tag in GitHub and copying the commit hash that v11 currently points to.
    Use that exact commit in the uses: line, for example uses: actions/stale@0123456789abcdef0123456789abcdef01234567 # v11.

  3. Keep the # v11 comment after the SHA so the pinned version is still easy to recognize during future updates.

  4. Alternatively, if you need automated dependency updates for GitHub Actions, enable a tool such as Dependabot for github-actions so it can open PRs when actions/stale publishes a newer trusted SHA.

💬 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