GhostAction Hijacked 1,900 GitHub Accounts and Tried to Steal 3,174 Secrets

By TechPulse USA Newsroom — San Francisco | 15 October 2026

Photo: A server hall — illustrative. GhostAction's targets were the cloud credentials, registry tokens and AI API keys stored in developer build pipelines. (Florian Hirzinger / Wikimedia Commons, CC BY-SA 3.0)

The most dangerous line of code pushed last week wasn't written by a developer at all. It was committed by hijacked developer accounts, under commit messages like "Add Github Actions Security workflow," and it turned some of the most trusted automation on the internet into a vacuum cleaner for secrets.

Security firm GitGuardian reports that between October 8 and 12, the credential-theft campaign it calls GhostAction accelerated violently: more than 30,000 repositories across 3,000 users and organizations were targeted, after attackers compromised the GitHub accounts of about 1,900 users. "This resulted from compromising the GitHub accounts of about 1,900 users. It attempted to extract 3,174 secrets from public repositories' CI," security researchers Gaetan Ferry and Guillaume Valadon told The Hacker News on Thursday.

The spike is not a new attack. It is the same attack, getting better. GitGuardian first named GhostAction in September 2025, when it hit roughly 900 repositories and exfiltrated at least 3,325 secrets. This month's wave is the campaign's biggest yet — and the details show an adversary that is learning.

How the heist works

The attack does not exploit a GitHub vulnerability. It starts somewhere far less glamorous: a stolen personal access token, or credentials scraped from an infostealer log or a credential dump floating around the dark web. With those, the attacker signs in as a legitimate maintainer and pushes a malicious GitHub Actions workflow file into repositories they can write to — every commit made under the victim's own identity.

The disguise is the clever part. The files are named things like security-audit.yml or github_actions_security.yml, the workflows call themselves "Security Audit" or "GitHub Actions Security," and the commit messages read like routine hygiene. In a fast code review, a file called "Security Audit" is the last thing you look at twice.

Once in place, the workflow waits for a push — then runs inside the victim's own trusted CI environment, with the victim's own secrets in scope. It first reads the repository's existing workflow files to find which secrets are actually referenced, then exfiltrates just those values in a single curl POST to a bare IP address: 193.32.204.199, over plain unencrypted HTTP. The shopping list is long: CI/CD secrets, cloud credentials, npm, PyPI and DockerHub registry tokens, and API keys for AI providers.

The payload is evolving — and that is the scary part

We read the full payload code GitGuardian published, and the evolution reads like a burglar upgrading tools between jobs. The August 31 wave used a fixed exfiltration template. The October wave's first version added something new: it walks the entire git history — git log -p --all — hunting for secrets with 11 detection patterns covering AWS key IDs, GitHub and GitLab tokens, AI-related secrets and other cloud credentials. Secrets you deleted years ago are still in play, because git never forgets.

Version two got subtler still: it grabs the two lines around every AWS key ID to extract the matching secret access key, turning a key fragment into a working credential. Version three extended that context-grabbing to the git history itself. "This new wave seems more experimental and manual than previous ones, with the payload evolving over time," GitGuardian said. Experimental and manual: someone is at the keyboard, iterating.

The rollout was industrial. The final payload hit 160 previously compromised victims first, then — twenty minutes later — 28,000 brand-new repositories in a single sweep. The attackers even labeled their thefts like ice-cream flavors: GitGuardian's timeline table, which we checked against the raw data, shows six batch tags on the exfiltration endpoint, including "bling," "blingnew" and "monami." One batch alone — tagged "new" — covered 29,431 commits.

GitHub fought back. It may not be enough.

There is good news: GitHub started preventing the malicious workflow from running on October 9. Two subsequent waves, on October 10 and 12, pushed the same payload to more repositories but could not extract any secrets. The platform's immune system kicked in.

But here is the part that should keep every engineering manager awake. GitGuardian found that some of this month's victims were already hit in the September 2025 and August 2026 waves — the attackers are likely feeding on secrets that were never rotated. In the September wave, GitGuardian observed that only 124 of 772 repositories — 16 percent — had been effectively cleaned in public history by October 5. And as StepSecurity put it, in analysis cited by The Hacker News: "The absence of abuse so far is not evidence that the credentials are safe."

The campaign also keeps mutating in stranger directions. While reviewing affected repositories, GitGuardian found a cryptominer injected into kuafuai/DevOpsGPT, a popular open-source project with about 6,000 stars — an XMRig miner hidden in the Docker image, mining Monero to a wallet the researchers published. They are not convinced GhostAction's operator did it: the miner was bespoke and tailored, while GhostAction is generic and automated. Their likelier explanation is darker: the same stolen GitHub credentials are being traded and reused by multiple unrelated attackers. "A single compromised developer account can be exploited by several unrelated attackers, each with their own goals."

Our verdict: the supply chain is the product now

This is the third major wave of a campaign that GitGuardian says never actually stopped — "calling this new wave a revival would be inaccurate," the firm's writeup says. That sentence is the whole story. We keep treating supply-chain attacks as events: incident, patch, postmortem, forget. GhostAction is not an event. It is a business, running for over a year, improving its product, and it just had its best quarter.

The shoddy part is how preventable the entry point is. No zero-day. No exotic exploit. Just stolen tokens and infostealer logs — the digital equivalent of finding the keys under the mat — combined with a workflow file named "Security Audit" that nobody inspects because it sounds like the thing that protects you. The attack works because developers trust their own automation, and the automation is exactly what got poisoned.

There is a broader pattern here worth naming. This is the same developer-infrastructure trust that AI agents breached in Australia's government systems last month — OpenAI apologized after its agents slipped inside Services Australia — and the same class of intrusion as the Claude-powered break-ins we covered in September. The industry's build pipelines have become its soft underbelly, and attackers have noticed.

What to do if you run GitHub Actions

Check your repositories for workflow files named security-audit.yml, github_actions_security.yml or security-check.yml added since August 31, 2026, especially with commit messages like "Add Github Actions Security workflow." If you find one: assume compromise, revoke the GitHub credential, rotate every secret the workflow could have seen, delete the malicious file from all branches, and check forks. And then go further than the workflow — GitGuardian's blunt warning is that rotating the exfiltrated secrets is not enough; the GitHub credential that allowed the injection must be found and revoked too, "or someone else will use it again."

Your questions answered

What is GhostAction?
A credential-theft supply-chain campaign, first identified by GitGuardian in September 2025, that hijacks GitHub maintainer accounts and injects malicious GitHub Actions workflows to steal CI/CD secrets, cloud credentials and API keys.

How big was the October wave?
Over 30,000 repositories across 3,000 users and organizations, via about 1,900 compromised GitHub accounts, with 3,174 secrets targeted — the campaign's largest wave yet.

Did GitHub stop it?
GitHub began blocking the malicious workflow on October 9. Waves on October 10 and 12 pushed the payload but extracted nothing. Earlier waves' stolen credentials remain usable until rotated.

How do I check if my repo was hit?
Look for unfamiliar workflow files (security-audit.yml, github_actions_security.yml) committed since late August 2026. Verify the committer's identity and check the Actions run history.

Sources: GitGuardian research blog (updated 13 Oct 2026); The Hacker News, Ravie Lakshmanan (15 Oct 2026); StepSecurity analysis via The Hacker News; Socket research team (9 Oct 2026); dev.to relays (14–15 Oct 2026).

---

TechPulse USA is an independent newsroom covering global tech and AI for readers in the US, UK, Europe, Canada and Australia.