Improve Actions security

[Marcono1234]

Select Topic Area

Product Feedback

Body

Foreword

This is intended as feedback / suggestions for the GitHub Actions team, but anyone else feel free to share your thoughts on this as well.

There are multiple aspects of GitHub Actions which make their usage insecure or risky. The sections below try to mention some of them, explaining the issues with them and proposing potential solutions. There are definitely more risks which are not covered here. The issues here are not new, they have been publicly discussed in the past already, for example by GitHub's Security Lab.

If you notice anything which I describe incorrectly below, please let me know. Also, the proposed solutions below are based on my naive perspective on this, maybe there are limitations which prevent implementing these solutions, or there are better or more effective solutions.

---

pull_request_target stale branches

For pull_request_target a big problem is that it runs based on the target branch of the PR (the Security Lab post Keeping your GitHub Actions and workflows secure Part 4 mentions that as "Lurking Threats in Non-Default Branches").

This is quite problematic because:

• Many users and even security researchers might not be aware of it, so workflows whose vulnerable pull_request_target is claimed to be fixed, might still be vulnerable on non-default branches
• Finding out which branches are affected by vulnerable pull_request_target workflows is difficult and time consuming
• Fixing vulnerable pull_request_target workflows requires coordination with all project members to avoid someone pushing a feature branch with the vulnerable workflow in the meantime again
• Non-default branches with vulnerable pull_request_target workflows might go unnoticed by security researchers and tooling, if the default branch is not vulnerable
• It might put forks at risk if they still contain the vulnerable pull_request_target workflow and a malicious user creates a PR against it
  (maybe the risk is lower because the owner of the fork needs to enable Actions there, which users sometimes do to test things though; and workflows might not run there for first-time contributors?)

Proposed solutions

• pull_request_target without branches filter only runs for the default branch
  • if no branches filter is specified and a PR is created against a non-default branch, the workflow fails (!= skipped) with an informative message (mentioning also the security aspect / linking to the GitHub Docs), so that maintainers can adjust the workflow in case they want to support non-default branches
  • the branches filter can be used to enable additional branches
• Maybe: Disable pull requests on (!= from) repository forks by default (related feature request to support disabling pull requests)

Impostor commits

When the uses: clause of a workflow pins an action to a commit SHA (e.g. uses: actions/checkout@<commit-sha>), then this commit might not actually be part of the referenced repository, but instead be only in a (potentially malicious) fork of it. This is called impostor commit.

So when a malicious user creates a PR claiming to update actions/checkout@<commit-sha> in your repository, they might actually point it to a malicious commit in their fork. Many users are probably not aware of this quirk of GitHub, and might fall for it. This can be made even more convincing if the malicious user uses tools to generate a commit with specific SHA so that it looks very similar to a commit from the real repository.

Proposed solutions

• in the context of GitHub workflow files, impostor commit references should be rejected
  There seems to be no valid use case where this behavior provides any advantage, and its only effect is that it deceives users.

Cache poisoning

When a workflow runs for a branch within a repository (e.g. the case for pull_request_target) and is processing data from a malicious user, it might allow them to write to the cache of the repository, which then poisons other workflow runs which restore the cache.

This can happen even if the vulnerable workflow itself does not perform any caching, an expression injection vulnerability might already suffice to exploit this, see also AdnaneKhan/Cacheract#16.

Proposed solutions

• only allow cache write permissions for push events, all other events should only have at most read permissions
  Caching is intended to speed up subsequent builds. However, except for push events the underlying source code did not change so there should normally not be any need to update the cache. And in the worst case the next build is a bit slower, but the advantage of eliminating large attack surfaces for cache poisoning should probably be more important here.
  Maybe cache write permissions would also make sense for pull_request, but then it would have to make sure that this cannot be exploited by a user who forks the repository of a victim, poisons the cache of their fork and then creates a PR from the victim repository to their fork (or similar), poisoning the repository of the victim. In that case the cache should be per PR (in case it isn't already).

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Marcono1234]

Also, maybe there should be a way for a pull_request workflow to allow limited write permissions to that same pull request¹. It is problematic that currently the only choices are: no permissions (pull_request) or full permissions² (pull_request_target / workflow_run).

Footnotes

1. But only to that same pull request and not pull requests generally, and also only to certain non- / less dangerous actions, but not allowing merging or approving, such as: Adding a comment, removing / editing a comment (but only if the bot was the author?), adding / removing labels. ↩

2. You can reduce permissions, but general issues remain, such as cache poisoning (mentioned above) or the risk of accidental bugs such as a separate "privileged" job which is not supposed to handle untrusted content being vulnerable to expression injection, or an "unprivileged" job which is supposed to handle untrusted user content also having access to a secret.
   Or you combine pull_request (unprivileged) and workflow_run (privileged). But having to use two separate workflows for this is error-prone and possibly increases the chance of introducing other vulnerabilities. ↩

[gregose]

@Marcono1234 thanks for the feedback here, we are definitely digging into these areas of how to make Actions more secure by default.

pull_request_target stale branches

I wanted to share that we are making progress in this area by restricting the executed workflows to the default branch for pull_request_target. You can read about the details at https://github.blog/changelog/2025-11-07-actions-pull_request_target-and-environment-branch-protections-changes/. These changes will ship Dec 8, 2025 and we are collecting feedback on this (and other Action's security improvements) at https://github.com/orgs/community/discussions/179107. Would love your continued feedback there!

/cc @Steve-Glass

[Marcono1234]

Yes I just noticed it (it came up in zizmorcore/zizmor#680 (comment)). Thanks for making Actions more secure!