The GitHub Actions Worm Read Secrets You Deleted, So Rotating One Is Not Enough

On 8 October two stolen maintainer accounts wrote a single file into every repository they could reach. The file was .github/workflows/security-audit.yml, it has no security function, and it posts what it gathers to one hard-coded address. The commit messages, “Add security audit workflow” and “Update security audit workflow”, read like routine upkeep in a diff.

Researchers at Socket, GitGuardian and StepSecurity each tracked the burst. The accounts belonged to Takashi Kitao, author of the pyxel game engine, and Henry Wu, the original author of Uber’s athenadriver. The Wu account wrote to 318 repositories in 16 minutes, 279 of them forks. Decade-dormant projects were hit alongside active ones, which points at automated enumeration rather than a chosen target list.

The workflow gathers two unrelated kinds of secret

The inherited half is the older GhostAction trick. Before the file is committed, the repository’s existing workflows are read for the names of the Actions secrets they use, and those exact names are written into the payload. For pyxel that list was CARGO_REGISTRY_TOKEN, PERSONAL_ACCESS_TOKEN, PYPI_PASSWORD and PYPI_USERNAME. Those publishing credentials let an attacker ship a malicious release of a package users already trust.

The new half is what forces the wider cleanup. The workflow checks out every branch and tag with fetch-depth 0, then runs git log -p –all and matches thirteen credential patterns against the whole history. A key a developer committed in 2019 and deleted the next day is still in that buffer, because the read covers commits rewritten off the default branch that stay reachable from a stale tag. It also captures the lines around each AWS key ID, since the ID alone authenticates nothing. Anthropic, OpenAI and OpenRouter keys are on the pattern list too. Everything leaves in one plain HTTP request to a hard-coded IP address, so DNS-based blocking never sees a domain to stop.

Rotating the secret you can see will not undo the commit

Here is the trap. The reflex after a CI breach is to rotate the repository’s Actions secrets and move on. That closes the inherited half and nothing else. The history sweep already left with a copy of every key that ever touched a commit.

The vendor guidance is blunt. Socket writes that rotating current Actions secrets no longer addresses the exposure. Every credential that ever appeared in the repository has to be treated as exposed, across all thirteen categories, and any AWS activity after the exposure window needs a CloudTrail review.

The cleanup rate from the earlier wave shows how hard that message lands. Of the 772 repositories hit between 31 August and 30 September, only 124, about 16 percent, had the workflow removed from observed public history by 5 October. GitGuardian counted 3,669 workflow runs across 605 repositories, and only 499 executed. The campaign never really stopped. The Hacker News tracked the same wave.

One checkbox broke the chain

Almost every mitigation is a rotation or a version bump. One is neither. A repository that required approval for workflow runs from outside collaborators stopped the attack outright, because the account that pushed the malicious commits could not approve its own work. StepSecurity watched two re-triggered runs stall in the action_required state. That single setting was the only control observed to break the exfiltration, and it is a checkbox most teams turn off for speed.

Add branch protection on .github/workflows/* so a stray commit cannot land a workflow on the default branch, and push protection on secret scanning so a key is caught at the door. GitHub’s hardening guide covers both. Then run the history scan across every repository the compromised account could write to, and enumerate by permission rather than by expectation. The 279 forks in the Wu namespace each carry the file, so any fork that enabled Actions afterward inherited the problem. The wider lesson is that a CI system trusts a file nobody reviewed.

Three questions for your own estate. Does any repository you own run workflows from a branch an outsider can write to? If a key was committed and deleted last year, could you rotate it today? And when a workflow named after a security audit shows up in a diff, would anyone open the file before it runs?

Related reading. A single prompt took over every agent in an AWS region, and last week’s NetScaler patch is still vulnerable as a SAML identity provider. Both show the same shape, a fix that closes the door without clearing the room.