Page History

...

Builds triggered by the pull_request_target event (as opposed to pull_request) by default check out the 'target' branch of the PR, and run with a 'permissive' GITHUB_TOKEN. It is common for such workflows to As long as only code from the trusted/reviewed 'target' branch is executed, this is fine.

Some such workflows switch to the code from the PR that triggered the workflow. This is dangerous, as any code that is loaded from the repo and run after the switch (including actions, scripts, build tools and test code) may be untrusted, and will have access to the GITHUB_TOKEN. Therefore we recommend against doing this, and suggest to split the job into an untrusted pull_request-triggered part and a trusted workflow_run part as documented in the next section:

Builds triggered with workflow_run

A common technique for building untrusted code but also using privileges to act on the build result is to split the build into two parts: a low-privilege one triggered by pull_request that runs the untrusted code, stores the result in an artifact, and triggers a second, high-privilege build with workflow_run  that acts on that result.

...

• Always extract into a directory separate from the trusted code in a step before checking out said  trusted code. This stops files extracted from the archive from clobbering trusted code.
• A separate directory can also prevent files in the artifact impersonating often used python modules like pip  as running python -m pip ...  would execute a pip.py file in the cwd
• Validate any content you retrieve from an artifact before you use it to avoid command injection, especially in steps using bash  and Github Actions macros.
  • This includes using cat  on such files as well as putting their content into environment variables (a popular exploit is to modify LD_PRELOAD, some examples ), step outputs to use via ${{ steps.id.outputs.sus_content }} to be used in e.g. if  in bash

An example of a job that is split into two parts like this is the NuttX PR labeler, https://github.com/apache/nuttx/blob/master/.github/workflows/labeler.yml and https://github.com/apache/nuttx/blob/master/.github/workflows/pr_labeler.yml.

Builds triggered with issue_comment 

...