Supply Chain Security

GhostAction Returns: What a GitHub Actions Worm Teaches Us About Trusting Third-Party Scripts

GhostAction compromised 500+ GitHub accounts and hit tens of thousands of repos. Here’s what it teaches website owners about trusting third-party scripts.

A credential-stealing campaign known as GhostAction has compromised hundreds of GitHub accounts and planted a malicious workflow across tens of thousands of repositories. It is not a CSP or browser story on the surface, but the mechanics behind it say something uncomfortable about every third-party script, package or integration a website leans on, including the ones a Content Security Policy is meant to keep in check.

What happened

Researchers at Socket and GitGuardian have been tracking GhostAction, a credential-theft campaign that spreads by hijacking legitimate GitHub maintainer accounts rather than exploiting a bug in GitHub itself. In one wave, an attacker used the compromised account of Takashi Kitao, author of the pyxel game engine, to push a malicious workflow to 27 repositories. A second compromised account, belonging to Henry Wu, was used to push the same workflow to 318 repositories in a sixteen-minute window.

Socket reports that more than 500 GitHub accounts have committed the workflow to tens of thousands of repositories since 7 October 2026. GitGuardian separately logged 772 public repositories across 373 users in an earlier wave between 31 August and 30 September. An even earlier GhostAction wave, in September 2025, hit 817 repositories belonging to 327 users and exposed 3,325 secrets. This is not a one-off incident. It is a recurring technique that keeps finding fresh accounts to abuse.

How the worm spreads

The chain starts with a leaked personal access token, most likely picked up from an earlier breach or an exposed secret rather than a flaw in GitHub's own defences. From there, the attacker uses the stolen credential to scan the victim's existing workflow files for clues about what secrets are in play.

A new workflow, disguised with an innocuous name such as security-audit.yml or github_actions_security.yml, is then pushed to the repository's default branch under the maintainer's own identity. It is set to run on manual dispatch or on any push to any branch or tag, which gives the attacker a wide and quiet trigger surface. Once running, it checks out the full git history and scans both the working tree and that history for thirteen credential patterns, covering AWS keys, AI provider keys and source-control tokens among others. Anything it finds is sent by curl to a hard-coded IP address over plain, unencrypted HTTP.

The secrets harvested in this wave reportedly include AWS keys, API keys for Anthropic, OpenAI and OpenRouter, and GitHub and GitLab tokens. Because the malicious workflow is committed to the repository itself, it also propagates automatically through forks and mirrors, which is one reason the numbers climb so quickly.

The real lesson: trust is transitive

Neither Takashi Kitao nor Henry Wu did anything wrong. Their code was fine when people started depending on it. What changed was who controlled their credentials, and the moment that changed, every repository that trusted their commits inherited a problem it never agreed to.

That is exactly the risk a website takes on every time it loads a script from a CDN, an analytics provider, a chat widget or an ad network. A Content Security Policy that allows script-src to include a third-party domain is making the same bet GitHub's maintainers made when they accepted a dependency: that the party on the other end stays trustworthy for as long as the relationship lasts. GhostAction is a reminder that the bet can turn bad long after the original review, with no warning beyond a routine-looking update.

The failure mode is also familiar to anyone who scans headers for a living. GhostAction's workflow hid in plain sight by looking like ordinary automation and by exfiltrating over a protocol nobody was watching closely. A compromised third-party script on a website behaves the same way: it often arrives through a channel that was already allowed, and it rarely announces itself. The only practical way to catch it is to notice when something allowed starts behaving differently, not to assume that approval once is approval forever.

What to do about it

If you maintain repositories, treat this as an incident rather than a settings tweak. Socket and GitGuardian recommend checking for workflow files named security-audit.yml or github_actions_security.yml going back to the end of August 2026, and assuming compromise if you find one. Revoke the GitHub credential involved rather than just rotating it, rotate every secret the scan could have reached (not only the ones currently in use), delete the malicious workflow from every branch, and check forks and mirrors, since they inherit the file automatically and can trigger it the moment Actions is enabled on them. Longer term, standard GitHub Actions hardening still helps: require approval for workflow runs triggered by outside collaborators, turn on secret scanning with push protection, and pin third-party actions to a commit SHA rather than a floating tag.

The same discipline applies to the scripts a website serves to visitors:

  • Treat every third-party script, tag or widget as something that can turn hostile after you have approved it, not just at the point you first add it.
  • Use Subresource Integrity on scripts loaded from a CDN, so a changed file fails to load rather than running silently.
  • Keep a tight Content Security Policy that limits script-src to domains you actually need, so an unexpected new origin is blocked by default rather than trusted by omission.
  • Watch your CSP reports for new or changed script sources. An origin that was never there before, or one that starts behaving differently, is often the earliest external signal that a provider you trusted has been compromised.

GhostAction will not be the last campaign to abuse a trusted identity instead of a software flaw. The organisations that catch it quickly will be the ones already watching for the moment something they approved starts acting differently, whether that is a GitHub Actions workflow or a script tag on a checkout page.

Sources