How One Pull Request Can Steal GitHub Actions Secrets

A pull request does not need to be merged to become dangerous inside a privileged GitHub Actions workflow. This video shows how to trace the trust boundary, recognize unsafe "pull_request_target" designs, and separate untrusted tests from trusted automation. You will learn: why "pull_request" and "pull_request_target" create different security contexts how a later checkout, build script, test hook, or untrusted input crosses the boundary why tokens, repository secrets, runners, and persistent caches change the blast radius how cache poisoning can influence a later trusted workflow how to design separate untrusted and trusted execution lanes the three questions to ask during every workflow review Important caveat: "pull_request_target" is not automatically vulnerable. The dangerous combination is privileged context plus execution or interpretation of contributor-controlled material. GitHub's newer checkout and cache protections block common paths, but they do not replace least privilege and explicit trust separation. Chapters: 00:00 A pull request reaches privileged assets 00:27 Nothing was merged—where did privilege come from? 01:03 The two trust zones 01:38 "pull_request" vs "pull_request_target" 02:16 The actual trust-boundary failure 02:47 Where untrusted execution hides 03:19 YAML is only the doorway 03:48 Tokens, secrets, and cache 04:24 How cache poisoning survives a run 05:26 The poisoned cache remains 05:51 GitHub's newer guardrails 06:32 What the common protection blocks 06:56 What the protections do not cover 07:34 Build a safe untrusted lane 08:11 Build a narrow trusted lane 08:45 The three-question workflow audit 09:25 Final takeaway Subscribe to ‪@DevOpsCorner‬ for production DevOps explained through failures, security boundaries, migration decisions, and real operator consequences. Which GitHub Actions event or permission is hardest to review safely in your repositories? #GitHubActions #DevSecOps #CICD