GitHub Security Lab

Today we are shipping the next change to make GitHub Actions secure by default and disrupt supply chain attacks: the Actions cache is now read-only for untrusted workflow triggers. This one directly addresses a class of attack that security researchers have been demonstrating for years, most notably Adnan Khan's work on cache poisoning. The Actions cache is shared across workflows that run on a repository's default branch. A low-privilege or vulnerable workflow, like a pull_request_target with a script injection, a pwn request, or an agent with prompt injection, can poison that cache. A more privileged workflow, like a scheduled publish job, then restores the poisoned entry and runs attacker-controlled code with its secrets. This has been the escalation path behind several recent supply-chain incidents. This change applies least privilege to the cache. Events that are triggered by users with write access and commonly write the default-branch cache, like push and schedule, keep full read-write access. Untrusted triggers, meaning those that can be fired by users without write access to the repository, now receive a read-only cache token by default. We are also working on controls to let teams go further and restrict cache reads and customize cache access for their most sensitive workflows. If you have input on how that should work, we are gathering feedback in the GitHub Community discussion linked in the comments. The full changelog, including which triggers keep read-write caching, is linked in the comments. The Actions product and engineering teams have been crushing it, getting these supply chain hardening releases out the door. Quickly iterating on ideas, scoping their real impact, and making the hard calls that matter. It has been a great group to work with.

Today we shipped Workflow Execution Protections for GitHub Actions, a core component of our 2026 security roadmap Gregory Ose and I published in March. Built on GitHub's ruleset framework, Workflow Execution Protections give administrators the ability to control who can trigger workflows and which events are permitted to run them. These policies can be enforced consistently across enterprises, organizations, and repositories. This gives organizations a centralized way to govern workflow execution and reduce risk from commonly abused triggers such as pull_request_target. I'm incredibly proud of what the team accomplished here. A huge thank you to the Actions engineering team for their partnership in bringing this feature to life over the past several months. Changelog 👉 https://lnkd.in/gzx9g2zT

Today we shipped actions/checkout v7 that refuses the most common pwn request patterns by default. Pwn requests are one of the most widespread and damaging classes of GitHub Actions vulnerabilities. A workflow using pull_request_target runs with repository secrets and a privileged token. Check out the head of an unreviewed fork pull request inside one, and attacker-controlled code runs with all of it. This has been the root cause of many recent and historical supply-chain incidents. In March I started iterating on this idea with the Actions product and engineering teams. There are still valid reasons to check out a fork's head, as long as you never execute it, and removing the capability would just push developers toward less auditable patterns like a manual git checkout in a run script. So we followed the pattern of APIs like React's dangerouslySetInnerHTML: keep a clear, deliberately named escape hatch, and funnel developers to documentation on the risks before they reach for it. The opt-out is named allow-unsafe-pr-checkout, so it is auditable by static analysis and signals to reviewers that the workflow is operating in a potentially unsafe way. Secure by default does not always mean removing a risky behavior. It means a developer has to understand the risk and opt in deliberately. We are also backporting the protection to all currently supported majors on July 16, so workflows on a floating tag like actions/checkout@v4 become secure by default with no work from the developer. Huge thanks to Steve Glass and the Actions team for partnering on this and shipping it. There is always more we can do, and more changes are coming to make Actions secure by default. I think the most impactful ones are still ahead. 🔒 Changelog and guidance on using pull_request_target safely are in the comments.