The Monsters in Your Build Cache - GitHub Actions Cache Poisoning

Introduction UPDATE 01/23/25 - Some of the techniques in this blog post no longer apply, however the core technique is still valid: Cache poisoning allows workflow lateral movement. The big change is that you can no longer write to the cache after the workflow job finishes, these means you have to get creative by performing the entire poisoning operation in-build. Thankfully, we now have Cacheract. I’ve personally been working on a tool to detect Pwn Request vulnerabilities at scale, and one of the “false positive” cases was when a workflow checked out and ran user-controlled code, but only had a GITHUB_TOKEN with read access and no secrets. This makes it just as secure as a workflow on pull_request, right? I turned out to be wrong. There is a way to escalate by smashing caches, turning GitHub’s cache eviction features into a weapon, and replacing cache entries with new, poisoned entries. The best part? It’s all working as intended. In this blog I will introduce GitHub Actions privilege escalation and lateral movement technique I’m going to call “Actions Cache Blasting”.