Your GitHub repository might already be carrying a workflow you never wrote, because researchers just disclosed an ongoing credential-theft campaign that compromised two high-profile open-source maintainer accounts, pushed a malicious workflow into more than 340 repositories, and shows no sign of slowing down, since Socket has already identified over 500 GitHub accounts committing the same file to tens of thousands of repositories since October 7, 2026.

The activity is being attributed to GhostAction, a supply chain campaign that first surfaced in September 2025, and this round is both larger and faster than the original wave.

What Makes the GhostAction Campaign So Dangerous

Most supply chain attacks need something novel. A zero-day, a poisoned dependency, a typosquatted package.

This one doesn't. It uses the access a maintainer already has, and it uses it while wearing that maintainer's name.

The malicious workflow lands on the default branch under the victim's own identity. To anyone reviewing the commit, it looks like the project's own author added a security audit step. That's the disguise, and it's a good one.

The scale in that last row is the old wave. The new one is already larger.

Breaking Down the Two Account Compromises

Two maintainer accounts anchor the timeline, and the contrast between them tells you a lot about how the operator works.

Takashi Kitao, author of the pyxel game engine with 18,400 stars, had his account used to push the workflow to 27 repositories starting at 13:20 UTC.

Henry Wu (henrywoo), original author of Uber's athenadriver, had his account used to push the same workflow to 318 repositories in a 16-minute window, between 21:10 and 21:26 UTC.

Twenty-seven repos in one push, then 318 in sixteen minutes eight hours later. The second account was a bigger lever, and the operator pulled it hard.

Both pushes came from legitimate accounts. No exploit, no breach of GitHub itself. Just working credentials.

The Attack Chain, Step by Step

The whole sequence is short enough to fit in five lines.

The attacker obtains a maintainer's GitHub credentials, most likely a leaked personal access token pulled from infostealer logs or a credential dump.

Workflows within the repository are get scanned for secrets as a step of reconnaissance.

A workflow disguised as a security audit is injected into the default branch, committed under the victim's own identity.

The embedded payload extracts what it finds and sends it to an attacker-controlled endpoint using curl.

That's it. No novel exploitation, no chained vulnerabilities. Just stolen tokens and patience.

What the Malicious Workflow Actually Does

StepSecurity broke down the workflow's behavior, and the trigger conditions matter as much as the payload.

It fires on workflow_dispatch and on an unfiltered push. Any branch, any tag. There's no path filtering, no branch restriction, no event scoping.

It checks out with fetch-depth: 0, which pulls the full git history rather than a shallow clone. That setting is the tell that this isn't a real security audit.

Then it runs a single step named "Audit," which does four things:

• Appends the repository's named secrets found during reconnaissance
• Scans the working tree for 13 credential patterns tied to AWS keys, AI services, source control services, and SaaS and cloud API keys
• Checks the entire git history for those same 13 patterns, harvesting credentials that were committed and later deleted
• Pairs AWS access key IDs with their matching secret access keys

That last item is the one that turns a pile of strings into usable credentials.

What Gets Stolen

The list is broad, and it's built for a cloud-native development shop.

Captured data includes repository-named GitHub Actions secrets, CI/CD secrets, and credentials sitting in the working tree or anywhere in the git history.

Specifically, the workflow hunts for:

• AWS access keys and their paired secret keys
• Anthropic, OpenAI, and OpenRouter API keys
• GitHub and GitLab tokens
• CI/CD pipeline secrets
• Cloud, AI, and SaaS credentials

GitGuardian's separate analysis of the campaign's earlier phase put the targeted secret count at 2,577 across a wider set, including SSH private keys, Azure credentials, DockerHub and GHCR registry tokens, database credentials, FTP credentials, Google Cloud and Firebase credentials, Telegram, Slack, and Discord bot tokens, and keys for Cloudflare, npm, PyPI, and AI providers.

One workflow, dozens of credential types. It doesn't need to know what you use, because it checks for everything.

The XMRig Miner Detail

In at least one case observed on August 30, 2026, the operators went beyond credential theft and modified the kuafuai/DevOpsGPT repository to embed an XMRig cryptocurrency miner in the project's Docker image.

That's a different kind of damage. Credential theft is quiet and recoverable, at least in principle. A poisoned Docker image spreads the problem to everyone who pulls it.

As of the latest reporting, no malicious package releases have been published using compromised publishing credentials. That's the good news, and it's fragile.

The Fork Problem Nobody's Watching

Here's the part that makes cleanup harder than it looks.

Socket noted that 279 forks in the henrywoo namespace each carry the workflow file. That's just one account's fork tree.

Forks inherit the workflow. When someone creates a new fork from an affected repository, or synchronizes an existing fork with its upstream, the malicious file comes along for the ride.

If Actions are enabled on that fork, subsequent pushes can trigger credential harvesting from a repository nobody thought to check.

Private forks and downstream mirrors are the most exposed, because private repositories are where committed credentials actually live. Public repos get scrubbed. Private ones sit.

And there's a detail worth pausing on. Across both accounts, every workflow run returns a repository identifier whether or not it found credentials. The operator isn't just harvesting secrets. They're building a map of reachable execution contexts, independent of what they steal.

How to Check If Your Repository Is Affected

Start with the filenames. Search your repositories for either of these since August 31, 2026:

• security-audit.yml
• github_actions_security.yml

Check every branch, not just the default. Check forks. Check archives and mirrors.

Then look for the workflow's signature behaviors:

• Triggers on workflow_dispatch or unfiltered push
• A checkout step using fetch-depth: 0
• A single step named "Audit"
• Outbound curl requests to 193.32.204[.]199

Any one of those alone might be coincidence. All four together is not.

How to Respond If You Find It

• Treat a confirmed find as an active compromise, not a close call.
• Revoke the GitHub credential that pushed it. Don't rotate it. Revoke it, then issue a new one.
• Rotate every secret the workflow could reach. That means repository secrets, organization secrets, environment secrets, and anything sitting in the working tree or git history.
• Rotate AWS keys specifically. If the workflow had time to run, paired access key IDs and secret keys are the highest-value item on the list.
• Delete the workflow from all branches. Not just the default. Every branch, every tag, every fork you control.
• Check your forks. Especially private ones, and especially ones with Actions enabled.
• Review Actions logs for the "Audit" step. If it ran, the exfiltration already happened, and your response shifts from prevention to containment.
• Check your Docker images if you use DevOpsGPT or downstream forks. Pull the tags and compare.

Why This Campaign Keeps Working

GhostAction first surfaced in September 2025. It's back a year later with a bigger wave, and the technique hasn't fundamentally changed.

The reason is that the underlying weakness isn't technical. It's structural.

Open-source maintainers hold broad access across many repositories. Their tokens live on laptops, in CI environments, in dotfiles. Infostealer malware harvests them constantly.

And once a maintainer account is compromised, the attacker inherits trust that took years to build. The commit looks legitimate because, from GitHub's perspective, it is.

GitHub Actions makes this worse in a specific way. Workflows run with access to the repository's secrets by default, they execute on push, and they can make outbound network calls. Those are features. They're also a ready-made exfiltration channel that ships with the platform.

The defensive takeaway isn't "stop using Actions." It's that your workflow files are a credential-adjacent attack surface, and they deserve the same review attention as your dependencies.

FAQ

What is the GhostAction campaign?

GhostAction is a supply chain attack campaign that compromises open-source maintainer accounts and uses them to inject malicious GitHub Actions workflows into repositories. The workflows masquerade as security audits and exfiltrate credentials.

Which workflow files should I search for?

Two filenames have been observed: security-audit.yml and github_actions_security.yml. Check every branch and every fork, not just your default branch.

Where does the stolen data get sent?

The payload exfiltrates data to a hard-coded IP address, 193.32.204[.]199, over plain HTTP using curl.

What credentials does the malicious workflow look for?

The list includes 13 types of credential formats ranging from AWS keys to AI service API keys, GitHub tokens, GitLab tokens, and cloud/SaaS credentials. It also appends repository-named GitHub Actions secrets and searches the entire git history for credentials that were committed and later deleted.

Is there any impact on GitHub.com?

No. GitHub has not been breached. The attacker uses the personal access tokens that have been leaked through the infostealer logs or credentials dump to commit the act.

What should I do if I find the workflow in my repository?

Assume compromise. Revoke the credential that pushed it, rotate every secret it could reach, rotate AWS keys specifically, delete the workflow from all branches, and check your forks. Then review Actions logs to see whether the Audit step actually ran.

Source: The Hacker News