The root cause is workflows that grant trust to untrusted inputs: pull_request_target that checks out and executes fork code with repo secrets, ${{ }} expressions that interpolate branch names/filenames into shell commands unsanitized, and issue_comment triggers with no author_association check.
These attacks only work when maintainers opt into dangerous patterns without guardrails.
We analyzed an autonomous bot (hackerbot-claw) that's actively scanning GitHub repos for exploitable Actions workflows. It hit Microsoft, DataDog, a CNCF project, and awesome-go (140k stars) achieving RCE in 4 out of 5 targets and exfiltrating a GITHUB_TOKEN. Full breakdown of the 5 attack techniques with evidence.
I think it says something about the current focus and mindset, that this got 12 upvotes, despite you having posted it three times.
We also care about security for CI and production workloads (actuated/slicervm). I would have liked to have seen more people becoming aware of this, and taking action.
The CLAUDE_CODE_OAUTH_TOKEN exfil is interesting. When our code review both runs, it thinks it has a valid LLM token, but it's a dummy API key that's replaced through MITM on egress. (Not a product, just something we've found very valuable internally.. )
Nx package on npm hijacked to steal cryptocurrency wallets, GitHub/npm tokens, SSH keys, and environment secrets through sophisticated exfiltration attack
How an AWS release rollback triggered the same red flags as a supply chain attack and why treating every semantic version tag change as suspicious is key to protecting your CI/CD pipelines
I’m Varun, CEO & Co-Founder of StepSecurity. StepSecurity detected and reported the tj-actions/changed-files compromise and has been actively helping the community recover from this incident.
To support you in understanding what happened and recovering swiftly, we’re hosting an Office Hour:
These attacks only work when maintainers opt into dangerous patterns without guardrails.
reply