← All postsOctober 12, 2026

GhostAction and the Secrets Hiding in Your Code

In the first week of October, security researchers at Socket and StepSecurity caught a renewed wave of an attack called "GhostAction" — hijacked GitHub accounts planting a fake workflow that quietly siphons off API keys and cloud credentials. It's aimed at developers, not consumers directly. But if your website, app, or any automation has credentials sitting in a GitHub repository somewhere, it's worth understanding what this attack goes after.

What actually happened

On October 8, attackers who'd compromised two well-known open-source maintainers' GitHub accounts pushed a workflow file to hundreds of repositories within about 30 minutes, and Socket's own tracking counted more than 500 compromised accounts by the next day. The workflow — disguised under an innocuous name like "security-audit.yml" — ran automatically and collected whatever secrets the repository's existing automation already had wired in: publishing tokens, cloud keys, Slack tokens, and API keys for AI services. StepSecurity's analysis of the newer version found it goes further, scanning a repository's entire git history rather than just its current files, looking for credentials someone committed and later deleted. Everything collected gets sent to a server the attackers control.

This isn't a one-off. GitGuardian first documented a GhostAction campaign in September 2025 that exposed more than 3,300 secrets across hundreds of repositories — this October wave is a repeat of a technique that already works.

Why this matters even if you've never touched GitHub

Most small business owners aren't maintaining open-source packages. But if a developer built your website, an internal tool, or an automation that talks to a cloud service or an AI API, the credentials for that almost certainly live in a repository somewhere — often one wired into a pipeline that deploys automatically. Those are exactly the kind of credentials this attack is designed to find.

A few things worth checking, whether or not you were anywhere near this specific incident:

  • Ask whoever maintains your code where your API keys and cloud credentials actually live, and whether any of them have ever been committed to the repository itself — even briefly, even in an old commit nobody thought twice about.
  • If you can't remember the last time your AWS, OpenAI, or Anthropic keys were rotated, that's worth fixing on its own, independent of this attack.
  • "We deleted the malicious file" isn't the fix. The real fix after an incident like this is rotating every credential the compromised workflow could have touched, not just removing what it added.

None of this requires understanding GitHub Actions or CI pipelines. It just requires knowing that "my code is private" and "my code has never leaked a secret" are two different claims — and only your repository's actual history can tell you which one is true.

Sources: