Update data/reusables/actions/pull-request-target-permissions-warning.md

Sharra-writes · JarLob · wrslatz · wrslatz · commit 61eda9661fc5 · 2025-07-10T09:40:08.000-04:00
Co-authored-by: Jaroslav Lobačevski &lt;jarlob@github.com&gt;
Co-authored-by: Will Slattum &lt;wrslatz@gmail.com&gt;
diff --git a/data/reusables/actions/pull-request-target-permissions-warning.md b/data/reusables/actions/pull-request-target-permissions-warning.md
@@ -1,2 +1,2 @@
 > [!WARNING]
-> For workflows that are triggered by the `pull_request_target` event, the `GITHUB_TOKEN` is granted read/write repository permission unless the `permissions` key is specified and the workflow can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch. To help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see [Understanding the risks of untrusted code checkout](/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#understanding-the-risks-of-untrusted-code-checkout) in the Security Hardening for GitHub Actions documentation and [Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the GitHub Security Lab website.
+> For workflows that are triggered by the `pull_request_target` event, the `GITHUB_TOKEN` may be granted read/write repository permission (unless the `permissions` key is explicitly specified in the workflow or repository/organization default permission are set to Read-Only) and the workflow can access referenced secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should be cautious if checking out untrusted code from the pull request with this event. Make sure that you do not build, or run untrusted code from the pull request. When `pull_request_target` is triggered against the main branch it shares the same cache as the other privileged workflows running in the context of the main branch. Running untrusted code on this trigger may lead to to cache poisoning. For more information, see [Understanding the risks of untrusted code checkout](/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#understanding-the-risks-of-untrusted-code-checkout) in the Security Hardening for GitHub Actions documentation and [Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the GitHub Security Lab website.

Original file line number	Diff line number	Diff line change
`@@ -1,2 +1,2 @@`
`1`	`1`	`> [!WARNING]`
`2`		-> For workflows that are triggered by the `pull_request_target` event, the `GITHUB_TOKEN` is granted read/write repository permission unless the `permissions` key is specified and the workflow can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch. To help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see [Understanding the risks of untrusted code checkout](/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#understanding-the-risks-of-untrusted-code-checkout) in the Security Hardening for GitHub Actions documentation and [Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the GitHub Security Lab website.
	`2`	+> For workflows that are triggered by the `pull_request_target` event, the `GITHUB_TOKEN` may be granted read/write repository permission (unless the `permissions` key is explicitly specified in the workflow or repository/organization default permission are set to Read-Only) and the workflow can access referenced secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should be cautious if checking out untrusted code from the pull request with this event. Make sure that you do not build, or run untrusted code from the pull request. When `pull_request_target` is triggered against the main branch it shares the same cache as the other privileged workflows running in the context of the main branch. Running untrusted code on this trigger may lead to to cache poisoning. For more information, see [Understanding the risks of untrusted code checkout](/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#understanding-the-risks-of-untrusted-code-checkout) in the Security Hardening for GitHub Actions documentation and [Keeping your GitHub Actions and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the GitHub Security Lab website.