GhostAction digs deleted API keys out of Git history

"Calling this new wave a revival would be inaccurate," GitGuardian wrote about GhostAction, and the October figures support that. GitGuardian's updated report says that between October 8 and 12, about 1,900 compromised GitHub accounts were used to push credential-stealing workflows into more than 30,000 repositories belonging to roughly 3,000 users and organizations.
At a glance
- GitGuardian counts more than 30,000 targeted repositories and 3,174 secrets the attacker tried to extract. Socket's first count of the October 8 burst was 346 repositories.
- The October payload checks out the full Git history and searches it with 11 regexes, so it can still reach keys that were deleted from the current code.
- GitHub started blocking the malicious workflow on October 9, and the waves on October 10 and 12 extracted nothing.
- According to The New Stack, GitGuardian has not determined how many distinct credentials actually reached the attacker.
All the sources agree on the method. The attacker commits a workflow disguised as a security job from the victim's own account, the workflow runs in CI, and whatever secrets it collects go over plain HTTP to 193.32.204.199. The New Stack contrasts this with the tj-actions/changed-files compromise, which poisoned a shared Action used by thousands of repositories. GhostAction exploits no flaw in GitHub Actions. It works by editing workflows directly with stolen developer credentials.
Socket saw 346 repositories, and GitGuardian later counted more than 30,000
The first public account of the October burst came from Socket's research team, cited in GitGuardian's October 9 update. Socket saw 346 repositories hit in two automated sweeps that each lasted minutes. Two compromised maintainer accounts, kitao and henrywoo, pushed a file named security-audit.yml into every repository they could write to, including kitao/pyxel (18,420 stars) and uber/athenadriver. In the September wave, most runs stalled waiting for approval. Socket says these runs executed, and it confirmed successful exfiltration.
GitGuardian's October 13 update covers more ground. It splits the campaign into batches using a label the attacker added to the exfiltration URL. The batch tagged "new" started at 14:07 on October 8 and accounts for 29,431 commits on its own. Smaller batches came before it: 1,713 commits with no tag, 162 tagged "bling", 112 tagged "blingnew" across two payload versions, and 159 tagged "monami". Two later batches, "mnsft" (84 commits on October 10) and "security" (65 on October 12), never executed.
The gap is mostly a question of timing and coverage. Socket's 346 is an early snapshot of two sweeps. GitGuardian's figure is a dataset spanning five days. The two counts do not contradict each other.
The payload went from named secrets to the whole Git history
Until October, GhostAction worked from a list. The attacker scraped each repository's legitimate workflows for <code>secrets.NAME</code> references and hardcoded those names into a single curl POST. The October payload went through three versions:
- Version 1 added scanning of the working tree and of <code>git log -p --all</code> with 11 secret-detection regexes. It was deployed to about 1,800 repositories.
- Version 2 made matching case-insensitive and grabbed the lines around AWS key IDs to pull in the matching secret keys. It went to about a hundred repositories that version 1 had already hit.
- Version 3 extended that context capture to history. It went first to 160 earlier victims and then, 20 minutes later, to 28,000 new repositories over October 8 and 9.
GitGuardian lists the regex targets as AWS key IDs, GitHub and GitLab personal access tokens, AI-related secrets and other cloud secrets. The New Stack is more specific: Google and Firebase keys plus tokens for Anthropic, OpenAI and OpenRouter, collected through <code>actions/checkout@v4</code> with <code>fetch-depth: 0</code>. GitGuardian reads the content scanning as a sign that the attacker was aiming at private repositories, since scanning public ones would have added nothing.
Our view: a key that was deleted from a later commit but never revoked is still a live key, and this payload was built to find exactly those. GitGuardian also reports that some October victims were already hit in the September 2025 and August 2026 waves, and that the attacker is likely relying partly on secrets that were never rotated. Wiz recommends rotating secrets and moving CI to short-lived OIDC access.
For scale, the first wave in September 2025 hit 817 repositories across 327 users and exfiltrated at least 3,325 secrets. Between August 31 and September 30, 2026, the workflow reached 772 repositories across 373 users and organizations and targeted 2,577 secrets. GitHub held most of those runs for approval. Of 3,669 runs across 605 repositories, 499 executed, in 32 repositories, and 336 succeeded, exfiltrating 26 secrets from 13 repositories. By October 5, only 124 of those repositories (16%) had been visibly cleaned in public history.
What we don't know
- How many credentials were stolen in October. GitGuardian counts 3,174 secrets targeted and confirms some exfiltration, but according to The New Stack it has no figure for distinct credentials received.
- How the accounts were compromised. The New Stack cites a StepSecurity analysis from October 9 that points to personal access tokens taken from credential dumps. That remains unconfirmed. StepSecurity has said before that red teams at multiple organizations have used this exact technique.
- What happened in private repositories. GitGuardian's figures come from public repositories and run records, so a version that targets private code is mostly invisible to that dataset.
On scale, GitGuardian's account has the better support. It rests on commit-level data with batch labels, start times and execution status, and it already includes Socket's early sweeps. On the question that matters most to victims, how much was actually taken, neither source has a number yet.
Up next
Claude Code Review leaves preview and runs 3x faster
Claude Code Review shed its research preview label, and most reviews got about 3x faster: ~20 minutes down to 6–10, running on every new PR for Team and Enterprise. How many minutes does a PR wait for its first human review on your team?
Related stories
- libheif bugs reached OpenAI repos and GitHub Enterprise
- Anthropic's OSS Scanner skips human review on bug reports
- Nvidia backs a shared exchange for agent failure reports
- OpenAI agents tried a RubyGems bug found only in July
- Code analysis pass lands in Shannon 3.0 pentester
- Patch the kernel bug OpenAI's agents turned into root
Comments
No comments yet. Be the first.
Join the conversation
Sign in to leave a comment. It appears after moderation.

