GhostAction Hijacked About 1,900 GitHub Accounts, and Secrets Nobody Rotated Kept Paying Out

Most supply chain attacks need a clever entry point. GhostAction does not. It logs in as the developer, using a credential that was stolen some time ago, commits a workflow file that looks like security tooling, and lets GitHub Actions hand over whatever secrets the repository holds. The October wave was the largest yet, and the reason it worked again is mostly that the last ones were never fully cleaned up.

That makes this less a story about a new technique than about remediation debt. A leaked token that is not revoked stays useful, a secret that is not rotated stays valuable, and a malicious workflow left on a branch stays ready to run.

A Campaign That Never Really Stopped

GhostAction was first reported in September 2025. According to GitGuardian's analysis, a new wave began around August 31, 2026 and pushed a workflow named github_actions_security.yml to 772 public repositories belonging to 373 users and organizations by the end of September. The workflow carried the names of secrets scraped from each victim's existing workflows and posted their values in a single request to a bare IP address over plain HTTP. GitGuardian counted 2,577 secrets targeted in that wave, including 446 SSH keys and deployment server credentials, 218 Azure credentials and 106 AWS access keys.

Then it accelerated. Between October 8 and 12, GitGuardian tracked more than 30,000 targeted repositories across about 3,000 users and organizations, roughly 1,900 compromised accounts and 3,174 targeted secrets. The newest payload no longer settled for the secrets configured in Actions. It scanned the working tree and the full git history for AWS, GitHub, GitLab and AI provider keys, which means a credential committed and deleted years ago was back in play. The third version went first to 160 previously observed victims and, about 20 minutes later, to 28,000 new repositories.

GitGuardian says GitHub began preventing the workflow from running on October 9, and later waves on October 10 and 12 extracted no secrets. Socket's analysis of the October 8 sweep, cited by GitGuardian, found the workflow pushed as security-audit.yml from two maintainer accounts into repositories including the Pyxel game engine, with 18,420 stars, and Uber's athenadriver database driver.

Stolen Once, Used Repeatedly

The entry point is ordinary. The Hacker News reports that the attackers used stolen personal access tokens or credentials taken from infostealer logs and dumps to get write access, then committed under the victims' own identities. GitGuardian researchers Gaetan Ferry and Guillaume Valadon describe the October activity as “more experimental and manual than previous ones, with the payload evolving over time.”

The repeat victims are the telling detail. Some repositories hit in October had also been hit in September 2025 and August 2026, and in 92 cases the attacker simply edited a malicious workflow left over from an earlier wave and pointed it at a new endpoint. As of October 5, only 124 of the 772 repositories from the late-summer wave, 16%, had been effectively cleaned in public history. The campaign kept working because its victims kept the same credentials and the same files.

“Rotating the secrets exfiltrated by the malicious workflow is not enough.”

GitGuardian, on GhostAction remediation

GitGuardian's point is that the secrets are only half of the incident. The GitHub credential that pushed the workflow is the other half, and leaked credentials are often reused by more than one actor. Rotate the cloud keys without revoking that token, and the attacker can simply commit a new workflow and collect the replacement keys.

There is one encouraging number. In the September wave, GitHub held most runs for approval: of 3,669 runs attempted across 605 repositories, 499 executed in 32 repositories, and 336 completed, exfiltrating 26 secrets from 13 repositories. A free setting that asks a human to approve a run did more to contain the damage than anything else in the record.

GitHub's New Controls, and Who They Cover

On October 20 GitHub put its package firewall into public preview. It sits between coding agents, CI/CD hosts or internal registries and the upstream registry, inspecting metadata requests and downloads and blocking packages that fail policy: a configurable cooldown on new versions, malware or vulnerability advisories, and supply chain checks such as attestation downgrades. Blocked packages go through an exception request workflow. GitHub's rationale is that agents and CI runners install dependencies “without a human in the loop.” The preview is free, with metered billing planned at general availability, but it is limited to GitHub Enterprise Cloud and covers only npm.

Earlier in the month GitHub also closed a publishing gap. Its October 2 change makes unvalidated npm trusted publishing configurations expire 48 hours after creation and rejects publishing tokens from issue_comment events. The fix followed research reported by Help Net Security, in which Bloom Security found more than 1,500 npm packages, with over 10 million downloads between them, exposed because npm trusted a repository by its name rather than its permanent ID. Bloom also estimates that agents on a typical endpoint install about 70 packages a month, and close to 350 on developer machines.

The two controls address what happens after a credential is used. Neither one revokes a token that has already leaked, and the projects GhostAction hit hardest, public open source repositories, are outside the firewall preview entirely. For most organizations the work is still theirs.

What Engineering and Security Leaders Should Do Now

• Search every branch for the two filenames. If security-audit.yml or github_actions_security.yml has appeared in any repository you own or depend on since August 31, treat every Actions secret and anything in its git history as exposed.
• Revoke the pushing credential, then rotate. Find the token or account that committed the workflow and kill it first. Rotating cloud keys while that access survives only hands the attacker fresh ones.
• Require approval for workflow runs. In the September wave it was the control that stopped most exfiltration, and it costs nothing. Pair it with branch protection on .github/workflows/ so direct pushes cannot add new workflows.
• Scrub history, not just the current tree. GhostAction's newest payload reads the full git history, so a key deleted in 2023 is still a live secret until it is rotated and purged from public history.
• Retire long-lived tokens. Replace stored cloud keys with workload identity federation and short-lived credentials, and audit personal access tokens against developers' devices, since infostealer logs are a named source.
• Put a gate in front of installs. Use GitHub's firewall where Enterprise Cloud allows it, and an equivalent cooldown and advisory check everywhere else, especially for coding agents installing packages without review.

GhostAction is not sophisticated, and that is the uncomfortable part. It succeeds on credentials that were already stolen and secrets that were already exposed, and every wave that goes uncleaned becomes the setup for the next.