Running code from forks with `pull_request_target`

First, I would like to give a huge thank you for delivering this feature.

However, it seems potentially dangerous as the usual process for CI is checking out the PR repo and the token has unlimited write access to the repo.

It’d be nice to limit the scope of the token to the PR triggered the event. In other words, the token should only be able to label, annotate, comment on or assign someone of that PR, and add a status or check to commits of that PR.

Until then, I think the documentation should warn against checking out and running code from public forks.

1 Like

Hi @KaTeX-bot,

Thank you for being here!

The event is similar to pull_request , except that it runs in the context of the base repository of the pull request, rather than in the merge commit. This means only workflows defined in the commit on the base repository are run.

Hence, any secrets are used in their own repository, should have related privilege based on its scope.


1 Like

Even it runs in the context of the base repository, people usually check out and test codes from the fork in pull request CI workflows. In this process, codes from the fork are executed.

If we run actions/checkout with persist-credentials: true (which is by default) or pass the token to the script, the token is exposed to the code run in the workflow, and a malicious actor may gain access to the token.

Hi @KaTeX-bot,

Yes, it could be. If forked repository is checked out or code executed with secrets token, the malicious actor may gain access to the token. ( eg:can directly get the token if malicious code export it)

Hence, for the event pull_request_target, user should be careful with the token and code used.

It’s recommended to raise a feedback ticket in below link where github product manager will take a review.[category]=actions

Thanks for help us improving!

@weide-zhou I’ve been trying to test this behavior and from what I can tell, with pull_request_target, the GitHub Actions workflows do not run against the forked code. Can you confirm this?

Ideally we want the behavior where it runs the workflows based on the base branch, but run’s the forked repo’s non-workflow code.

You need to checkout the correct commit:

    - uses: actions/checkout@v2
        ref: ${{github.event.pull_request.head.ref}}
        repository: ${{github.event.pull_request.head.repo.full_name}}

The topic opener is correct. The recommendation to explicitly checkout the PR head on pull_request_target may compromise your repository. More details -