...

When a security issue is fixed in a workflow triggered by pull_request_target, you must not only fix it on your main branch, but fix/delete all branches that have the vulnerable workflow, as PRs to those branches would still trigger the vulnerable code.

Workflows triggered by workflow_run  only run when this workflow also exists on the main branch, so removing/renaming it on the main branch may also help there.

Further mitigations

• (TODO: verify this advice is still current. using external actions but pinning them and having them reviewed by Infra might supersede this advice)NEVER use 3rd-party actions directly in your workflows - use the "submodule" pattern. Example PR Tobiasz Kędzierski  opened in SuperSet showing how this could be done. Also ASF INFRA allow-listed some of the popular Actions out there, including my "cancel workflow" action, but I there is no public list of those available. The nice things about submodules is that they do not bring action code to your repo. They link to commit hashes of the Actions, and that integrates well with the GitHub review process so that committers have better chance to review the changes before they are merged. By using submodules, you are automatically following the GitHub recommendations for hardening of security for 3rd-party actions.
• NEVER directly run code that might come with "forked" PRs in your workflows. There are certain exotic (but useful) workflows that are dangerous. For example, with "workflow_run" you might need to cancel duplicate workflows. Those workflows by default run with "master" code, but sometimes you might need to check out the incoming PR code for those. The host environment can have access (in various ways) to the "WRITE" GITHUB_TOKEN that has permission to modify your repository WITHOUT RESTRICTION OR NOTIFICATION. NEVER run the code that is checked out from the PR in your host environment. If you need to, run it in Docker Container to provide isolation from the host environment to avoid the "write" access leaking to users who prepare such a PR from their fork.
• NEVER install and run 3rd-party dependencies in the host of your build workflow code. Again there are ways those dependencies can obtain the "WRITE" GITHUB_TOKEN and change anything in your repository without your knowledge.  There are very common "schedule" and  "push" workflows that are especially prone to such abuse. Those run with "WRITE" access, and again there are ways to obtain the GitHub Token by these Actions and code that runs in your workflow. If you execute any 3rd-party code, run it in Docker containers to keep isolation from your "build" host environment to avoid leaking "write" access to those 3rd parties.
• If you REALLY HAVE TO  run untrusted code (for example as part of your build steps) - you should only do it inside a docker container that you should not pass any credentials to.
• If you build images from Dockerfile that is untrusted make sure you use .dockerignore which is  not coming from the PR, which  Ignores everything from context by default. Add **  as the first line and only adds (via !directory_path or !file_path ) the files that you need during the build