{"meta":{"title":"Script injections","intro":"Understand the security risks associated with script injections and GitHub Actions workflows.","product":"GitHub Actions","breadcrumbs":[{"href":"/en/actions","title":"GitHub Actions"},{"href":"/en/actions/concepts","title":"Concepts"},{"href":"/en/actions/concepts/security","title":"Security"},{"href":"/en/actions/concepts/security/script-injections","title":"Script injections"}],"documentType":"article"},"body":"# Script injections\n\nUnderstand the security risks associated with script injections and GitHub Actions workflows.\n\n## Understanding the risk of script injections\n\nWhen creating workflows, [custom actions](/en/actions/creating-actions/about-custom-actions), and [composite actions](/en/actions/creating-actions/creating-a-composite-action), you should always consider whether your code might execute untrusted input from attackers. This can occur when an attacker adds malicious commands and scripts to a context. When your workflow runs, those strings might be interpreted as code which is then executed on the runner.\n\nAttackers can add their own malicious content to the [`github` context](/en/actions/learn-github-actions/contexts#github-context), which should be treated as potentially untrusted input. These contexts typically end with `body`, `default_branch`, `email`, `head_ref`, `label`, `message`, `name`, `page_name`,`ref`, and `title`. For example: `github.event.issue.title`, or `github.event.pull_request.body`.\n\nYou should ensure that these values do not flow directly into workflows, actions, API calls, or anywhere else where they could be interpreted as executable code. By adopting the same defensive programming posture you would use for any other privileged application code, you can help security harden your use of GitHub Actions. For information on some of the steps an attacker could take, see [Secure use reference](/en/actions/security-guides/security-hardening-for-github-actions#potential-impact-of-a-compromised-runner).\n\nIn addition, there are other less obvious sources of potentially untrusted input, such as branch names and email addresses, which can be quite flexible in terms of their permitted content. For example, `zzz\";echo${IFS}\"hello\";#` would be a valid branch name and would be a possible attack vector for a target repository.\n\nThe following sections explain how you can help mitigate the risk of script injection.\n\n### Example of a script injection attack\n\nA script injection attack can occur directly within a workflow's inline script. In the following example, an action uses an expression to test the validity of a pull request title, but also adds the risk of script injection:\n\n```yaml\n      - name: Check PR title\n        run: |\n          title=\"${{ github.event.pull_request.title }}\"\n          if [[ $title =~ ^octocat ]]; then\n          echo \"PR title starts with 'octocat'\"\n          exit 0\n          else\n          echo \"PR title did not start with 'octocat'\"\n          exit 1\n          fi\n```\n\nThis example is vulnerable to script injection because the `run` command executes within a temporary shell script on the runner. Before the shell script is run, the expressions inside `${{ }}` are evaluated and then substituted with the resulting values, which can make it vulnerable to shell command injection.\n\nTo inject commands into this workflow, the attacker could create a pull request with a title of `a\"; ls $GITHUB_WORKSPACE\"`:\n\n![Screenshot of the title of a pull request in edit mode. A new title has been entered in the field: a\"; ls $GITHUB\\_WORKSPACE\".](/assets/images/help/actions/example-script-injection-pr-title.png)\n\nIn this example, the `\"` character is used to interrupt the `title=\"${{ github.event.pull_request.title }}\"` statement, allowing the `ls` command to be executed on the runner. You can see the output of the `ls` command in the log:\n\n```shell\nRun title=\"a\"; ls $GITHUB_WORKSPACE\"\"\nREADME.md\ncode.yml\nexample.js\n```\n\nFor best practices keeping runners secure, see [Secure use reference](/en/actions/reference/secure-use-reference#good-practices-for-mitigating-script-injection-attacks)."}