Merge v2.4 into v2.x - #1965
Conversation
Enable 2 new features when creating merge-up PR: - Add "merge-up" label - Assign the approver of the merged pull request Backport rector fixes and drivers-evergreen-tools update in order to make the CI pass
# Conflicts: # .github/workflows/merge-up.yml # rector.php # tests/Model/IndexInfoFunctionalTest.php
# Conflicts: # rector.php
| - name: Create pull request | ||
| id: create-pull-request | ||
| uses: alcaeus/automatic-merge-up-action@1.0.1 | ||
| uses: alcaeus/automatic-merge-up-action@1.1.0 |
There was a problem hiding this comment.
Semgrep identified an issue in your code:
alcaeus/automatic-merge-up-action@1.1.0 points to a mutable tag, so this workflow can start running different action code without any change here. If that tag is repointed, the new code would run with write access to contents, pull requests, and OIDC tokens.
More details about this
Create pull request runs alcaeus/automatic-merge-up-action@1.1.0, which is a mutable tag rather than a specific commit. If the action owner or anyone who compromises that repository moves 1.1.0 to a different commit, this workflow will silently run the new code with this job’s id-token: write, contents: write, and pull-requests: write permissions.
A plausible attack looks like this:
- An attacker gains control of the
alcaeus/automatic-merge-up-actionrepository or its release process. - They repoint the
1.1.0tag to a commit that adds a malicious step inside the action. - The next push to a branch matching
v[0-9]+.[0-9x]+triggers thismerge-upjob. - When
uses: alcaeus/automatic-merge-up-action@1.1.0runs, GitHub fetches the attacker’s new commit instead of the code originally reviewed. - That malicious action can read inputs like
ref: ${{ github.ref_name }}and then misuse the job token and granted permissions to push code, open or modify pull requests, or mint an OIDC token fromid-token: writefor follow-on access.
Because the reference is @1.1.0 instead of a full 40-character commit SHA, the exact code executed by this workflow can change 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.
Changeuses: alcaeus/automatic-merge-up-action@1.1.0touses: alcaeus/automatic-merge-up-action@<full-40-character-commit-sha>. -
Keep the human-readable version as an inline comment so the pinned revision is easier to maintain, for example
uses: alcaeus/automatic-merge-up-action@<sha> # v1.1.0. -
Resolve the SHA from the exact upstream release you intend to trust, and make sure it is the commit for
1.1.0, not a branch or shortened hash. Pinning to a commit prevents the action owner from silently moving the referenced version later.
Alternatively, if you control the action code and want to avoid third-party pinning, replace the external action with a local action reference such as uses: ./.github/actions/<action-name>.
💬 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.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Merge new changes from v2.4 into v2.x.
Commits
To resolve any conflicts, check out the temporary branch and run the following command:Resolving conflicts
To ignore from the remote branch, first reset the temporary branch to v2.x and manually merge using the `ours` merge strategy:Ignoring changes
Then, push the temporary branch to update the pull request.