GitHub CI Secret Stealer Rides 4,837 Hijacked Accounts Into 61,000+ Repositories
- Who should care: Every team that builds or ships through GitHub Actions, and anyone who has given a collaborator or bot a token with write access.
- What could go wrong: Every secret and cloud role your workflows can touch gets stolen, and the logs that would prove it are deleted.
- Do this: Search your repos for the probe pull request and commit titles below, then look for missing run numbers in the Actions tab.
- Worth remembering: Rotating keys won’t evict an attacker who has already planted a backdoor in AWS or Azure.
Introduction
A new wave of stolen GitHub logins is turning CI pipelines into credential vacuums. Since November 10, the GitHub CI secret stealer has used 4,837 hijacked accounts to probe 61,764 repositories. At least 1,806 of them have already leaked their secrets, according to Aikido Security.
What Happened in the GitHub CI Secret Stealer Attack?
Each attack starts with a harmless-looking pull request, “docs: dependency audit notes,” that only tests for write access. Where the stolen token can write, the attacker pushes a roughly 1,500-line shell stealer. It is usually tucked into an existing workflow under the commit “ci: refresh build cache.” Other copies hide in a new workflow or in a script wired to an npm postinstall hook.
After the job runs, the change is reverted within minutes, and the run and its logs are deleted. StepSecurity counted more than 21,000 injection commits in two days. On November 12, new copies switched from two exfiltration IPs to a Telegram chat, as SafeDep reported.
What’s the Impact?
The stealer takes every Actions secret, the workflow token, OIDC tokens, and secrets held in runner memory. It trades the OIDC tokens for AWS, GCP, and Azure sessions and opens IAM trust policies to anyone.
It also adds Azure federated credentials that keep working after you rotate secrets. That turns the GitHub CI secret stealer from a one-time leak into lasting cloud access. At least 50 victims publish npm, Go, Packagist, PyPI, or crates packages, so the damage can spread to everyone downstream.
Not a Stranger: The GhostAction Link
Accounts hit in October’s GhostAction wave were about 1,000 times more likely to be reused this week, The Hacker News reported. In more than 100 repos, the new stealer was added on top of October’s leftover workflow. Researchers haven’t tied the two campaigns to one actor, but the lesson is the same: secrets nobody rotated became the next way in.
How to Avoid the GitHub CI Secret Stealer
- Search your org for the probe title and for the commits “ci: refresh build cache,” “chore: add ci helper,” and “chore: add dependency audit workflow.” A gap in run numbers right after one of them means the stealer probably ran.
- Assume theft if it ran. Treat every secret, variable, and cloud role that workflow could reach as stolen. Also revoke the commit author’s tokens, sessions, and SSH keys.
- Hunt cloud backdoors. Look for IAM roles that trust any principal, unexpected new access keys, and Azure federated credentials with a “wfx” prefix.
- Lock down egress. Use an allowlist to block bare IPs and api.telegram.org from CI runners.
- Shrink standing access. Replace stored cloud keys with tightly scoped OIDC roles, and require code owner review on every change under .github/workflows.
GitHub CI Secret Stealer Indicators of Compromise (IOCs)
Researchers published network, commit, file and cloud indicators for this campaign. A hit on any of them in a repo you can write to, dated November 10 or later, means the account and every secret that workflow could reach should be treated as compromised.
Attack Your Pipeline Before a Stolen Token Does
This campaign worked because nobody was watching who changed workflows or what those workflows could reach. Secure.com’s AI teammates attack your pipeline first, harden what they find, and prove the fix, while your team sets the rules.
- Flags workflow changes from accounts and bots that have never touched CI before
- Maps which secrets and cloud roles each workflow can reach, so the blast radius is clear in minutes
- Catches open trust policies, rogue access keys, and unknown federated credentials across AWS and Azure
- Runs credential rotation as a governed playbook your team approves, with an audit trail for every step
- Tests runner egress the way an attacker would, then gives your team the fix
Attack. Harden. Prove. Repeat.
Conclusion
The GitHub CI secret stealer didn’t need a zero-day. It needed stolen logins, workflows nobody watched and secrets nobody rotated after October. Search for the commit titles, check your run numbers, and clean out your clouds before you call the incident closed.
