News Cyber Attacks

GhostAction hijacks maintainer accounts to plant secret-stealing GitHub workflows

On 8 October 2026, attackers used two compromised open-source maintainer accounts to push a fake "Security Audit" GitHub Actions workflow into 345 repositories. The workflow sends repository secrets, and credentials found anywhere in the git history, to an attacker-controlled server.

Published Updated
Illustration of a code repository tree where one glowing workflow file sends a stream of keys out to a distant server.

Key takeaways

  • Two compromised maintainer accounts pushed a fake "Security Audit" workflow into 345 repositories on 8 October 2026.
  • The workflow steals Actions secrets and credentials from the entire git history, not just current files.
  • Data goes over plain HTTP to 193.32.204.199, with no DNS lookup.
  • Rotating current secrets is not enough; rotate anything ever committed.
  • Requiring approval for workflow runs stopped the attack in one observed repository.

Attackers behind the GhostAction campaign used two compromised open-source maintainer accounts to push a credential-stealing GitHub Actions workflow into 345 repositories on 8 October 2026, security firm StepSecurity reported on 9 October.

What happened? #

According to StepSecurity's analysis:

  • From 13:20 to 13:44 UTC, the account of the author of the pyxel game engine was used to push the workflow to 27 repositories.
  • From 21:10 to 21:26 UTC, the account of the original author of Uber's athenadriver was used to push it to 318 repositories: 39 source repositories and 279 forks. That author still had write access to the Uber repository, so the workflow went straight to its default branch with no pull request.

The commits were made under the victims' real identities with the message "Add security audit workflow". StepSecurity says the most plausible way in is a leaked personal access token, for example from infostealer logs.

What does the malicious workflow do? #

The workflow, named "Security Audit" (security-audit.yml), runs on any push and checks out the full repository history. It then:

  1. Collects the repository's named GitHub Actions secrets, which the attacker had listed in advance.
  2. Searches the working tree for 13 credential patterns, including AWS keys, GitHub and GitLab tokens, Google, Slack and SendGrid keys, and Anthropic, OpenAI and OpenRouter API keys.
  3. Searches the entire git history for the same patterns, so a secret committed once and deleted later is still collected.
  4. Sends everything over plain HTTP to the IP address 193.32.204.199.

StepSecurity says the run log for the athenadriver repository shows the attacker's server acknowledged the upload four seconds after the workflow started.

How widespread is it? #

As of 9 October, StepSecurity found 378 repositories with a live malicious workflow on the default branch, a count that excludes forks. It found no malicious package releases published with the stolen publishing credentials at the time of writing, but warns that the exposure lasts until those tokens are rotated.

StepSecurity also observed one repository where the attack failed: it required approval for workflow runs, and the re-triggered runs stalled waiting for that approval.

How can teams check whether they are affected? #

StepSecurity suggests these GitHub code searches, replacing your-org with your organisation name:

org:your-org "AKIA_CTX_START"
org:your-org "c=monami"
org:your-org "193.32.204.199"

Other indicators include workflow files named security-audit.yml, github_actions_security.yml or security-check.yml, and commit messages such as "Add security audit workflow" or "Trigger security scan". StepSecurity says any such workflow that appeared since 31 August 2026 should be treated as a confirmed breach.

What should affected teams do? #

  1. Rotate every Actions secret and every credential ever committed to any branch, not only current ones.
  2. Find and revoke the compromised GitHub credential that allowed the push.
  3. Delete the malicious workflow from all branches, and check forks.
  4. Review workflow runs since 31 August 2026 for the indicators above.
  5. Hold releases until clean if publishing tokens such as PyPI, npm or crates.io were configured.
  6. Require approval for workflow runs and protect .github/workflows with branch protection.

Sources

  1. StepSecurity analysis of the October GhostAction wave, StepSecurity
  2. Report on the credential-stealing workflows, The Hacker News

Questions this raises

How do I know if my repositories are affected?
Search your organisation's code for "AKIA_CTX_START", "c=monami" or "193.32.204.199", and look for workflow files named security-audit.yml, github_actions_security.yml or security-check.yml.
Is deleting the workflow enough?
No. StepSecurity says to rotate every secret and every credential ever committed to the repository, and to revoke the GitHub credential that allowed the push.
Were malicious packages published?
StepSecurity found none at the time of writing on 9 October 2026, but the stolen publishing tokens stay usable until they are rotated.

Cyber AttackCybercrimeGitHub ActionsSupply Chain SecurityCredential Theft