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

Sharra-writes · web-flow · commit 833242ab8d48 · 2025-09-12T11:17:54.000-07:00
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` 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 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 {% data variables.product.prodname_actions %} documentation and [Keeping your {% data variables.product.prodname_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 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 {% data variables.product.prodname_actions %} documentation and [Keeping your {% data variables.product.prodname_actions %} and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the {% data variables.product.prodname_security %} 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` 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 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 {% data variables.product.prodname_actions %} documentation and [Keeping your {% data variables.product.prodname_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 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 {% data variables.product.prodname_actions %} documentation and [Keeping your {% data variables.product.prodname_actions %} and workflows secure: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests) on the {% data variables.product.prodname_security %} website.