GhostAction Campaign Returns, Compromising 340+ Repositories Through Malicious GitHub Workflows

Cybersecurity researchers have uncovered a renewed wave of the GhostAction supply chain attack, in which threat actors compromised open-source maintainer accounts and injected malicious GitHub Actions workflows into hundreds of repositories to steal sensitive credentials.

The campaign has targeted developer accounts associated with popular open-source projects, using workflows disguised as security audits to collect GitHub Actions secrets, cloud credentials, AI service API keys, and other sensitive information from repositories and their Git history.

According to StepSecurity, two compromised maintainer accounts were used to distribute the malicious workflow to more than 340 repositories. Socket separately reported that, as of October 9, 2026, it had identified more than 500 GitHub accounts associated with the malicious workflow activity.

Two Open-Source Maintainer Accounts Compromised

Researchers identified malicious activity involving two prominent open-source maintainers:

  • Takashi Kitao: The author of Pyxel, a game engine with approximately 18,400 GitHub stars. The compromised account was used to push a malicious workflow to 27 repositories beginning at 13:20 UTC.
  • Henry Wu (henrywoo): The original author of Uber's AthenaDriver project. His account was used to push the same workflow to 318 repositories within a 16-minute period, between 21:10 and 21:26 UTC.

The malicious changes were introduced under the maintainers' identities, making the activity appear to originate from trusted contributors.

Socket reported that the campaign had expanded significantly, identifying more than 500 GitHub accounts that committed the malicious workflow to tens of thousands of repositories since October 7, 2026.

GhostAction Supply Chain Attack Returns

GhostAction first came to light in September 2025, when researchers identified a supply chain campaign involving malicious GitHub Actions workflows and compromised developer accounts.

The earlier campaign affected 817 repositories across 327 GitHub users and resulted in the theft of 3,325 secrets, including PyPI, npm, and DockerHub tokens.

The latest activity follows a similar approach. Attackers introduce workflows with names such as Security Audit (security-audit.yml) or GitHub Actions Security (github_actions_security.yml). Despite their legitimate-sounding names, the workflows are designed to collect sensitive credentials and transmit them to an attacker-controlled server.

Researchers identified the IP address 193.32.204[.]199 as the destination used by the malicious workflows. The stolen information is transmitted over unencrypted HTTP.

How the Attack Works

The attack relies on compromised GitHub credentials and malicious workflow files rather than requiring a separate exploit against every affected repository.

The observed attack chain follows these steps:

  1. Credential theft: The attacker obtains a maintainer's GitHub credentials, potentially through leaked personal access tokens, infostealer logs, or credential dumps.
  2. Repository reconnaissance: The attacker examines repositories and their workflow files to identify potential secrets and valuable execution environments.
  3. Malicious workflow injection: A workflow disguised as a security audit is added to the repository's default branch using the compromised maintainer's account.
  4. Automated execution: The workflow runs when manually triggered through workflow_dispatch or following qualifying push events.
  5. Credential collection: The malicious code searches repository secrets, working files, and Git history for sensitive information.
  6. Data exfiltration: Collected credentials and repository information are sent to the attacker's server using curl.

Because the malicious changes appear to come from a trusted maintainer, they may escape notice during routine repository activity.

What the Malicious Workflow Steals

StepSecurity's analysis found that the workflow performs several operations to collect credentials and other sensitive data.

The workflow:

  • Collects named GitHub Actions secrets identified during reconnaissance.
  • Scans the working tree for 13 credential patterns associated with cloud providers, AI services, source-control platforms, and SaaS applications.
  • Searches the entire Git history for the same credential patterns, including credentials that were committed and later deleted.
  • Pairs AWS access key IDs with their corresponding secret access keys.
  • Sends the collected information to an attacker-controlled endpoint.

The workflow uses fetch-depth: 0, which retrieves the full Git history during checkout. This allows it to search beyond the current files for credentials that may remain in previous commits.

The targeted credentials can include:

  • AWS access keys and other cloud credentials
  • Anthropic, OpenAI, and OpenRouter API keys
  • GitHub and GitLab access tokens
  • DockerHub and GitHub Container Registry credentials
  • Azure, Google Cloud, and Firebase credentials
  • SSH private keys and database credentials
  • FTP credentials and other service API keys
  • Telegram, Slack, and Discord bot tokens
  • Cloudflare, npm, and PyPI publishing credentials

Access to these secrets could allow attackers to compromise cloud environments, access private source code, abuse AI services, or potentially publish malicious packages under trusted developer identities.

Researchers Report Hundreds of Affected Repositories

Multiple security research teams have reported findings related to the renewed campaign.

GitGuardian reported that GhostAction pushed the malicious workflow to 772 public repositories belonging to 373 GitHub users and organizations between August 31 and September 30, 2026.

The researchers identified 2,577 targeted secrets across the affected environment. These included cloud credentials, source-control tokens, container registry credentials, database passwords, and credentials for communication platforms and AI providers.

StepSecurity's investigation separately documented the two maintainer accounts used to distribute the workflow to more than 340 repositories.

Socket also reported identifying more than 500 GitHub accounts associated with malicious workflow commits since October 7, 2026.

These figures come from different investigations and reporting periods, so they should not be treated as a single deduplicated count of affected accounts or repositories.

Cryptocurrency Mining Activity Also Observed

Researchers also observed an incident involving the kuafuai/DevOpsGPT repository on August 30, 2026.

In that case, threat actors reportedly modified the repository to include an XMRig cryptocurrency miner in the project's Docker image.

This indicates that the campaign's risks may extend beyond credential theft. Compromised developer accounts and build workflows can potentially be used to introduce additional malicious code into software projects.

At the time of the reports, researchers had not identified malicious package releases published using credentials stolen during the campaign.

Why Forks and Mirrors Are at Risk

The malicious workflow may remain active in repositories even after the original compromise is discovered.

Socket highlighted that 279 forks in the henrywoo namespace contained the workflow file. If GitHub Actions are enabled, subsequent pushes could trigger credential collection.

Private forks and downstream mirrors may be particularly exposed because they can contain credentials or internal configuration files that are not available in public repositories.

Even when a workflow finds no credentials, it reportedly returns a repository identifier. This could help the attacker map accessible repositories and execution environments.

Deleting the workflow from the original repository may therefore be insufficient if copies remain in forks, mirrors, or other branches.

How Developers Can Protect Their Repositories

Developers and organizations should treat the presence of either identified workflow as a potential compromise.

Recommended response steps include:

  1. Search repository history: Check repositories and branches for security-audit.yml and github_actions_security.yml, including changes made since August 31, 2026.
  2. Revoke compromised credentials: Revoke the affected GitHub personal access token or other compromised account credentials and secure the account.
  3. Rotate exposed secrets: Replace potentially exposed cloud keys, AI API keys, package registry tokens, SSH keys, database credentials, and other secrets.
  4. Remove malicious workflows: Delete the unauthorized workflow from all branches and investigate forks, mirrors, and downstream repositories.
  5. Review GitHub Actions logs: Look for suspicious workflow executions, unexpected workflow_dispatch runs, unusual push-triggered activity, and outbound requests to 193.32.204[.]199.
  6. Audit cloud and service activity: Review authentication logs and API usage for suspicious access, unexpected resource creation, unusual spending, and unauthorized changes.
  7. Inspect recent commits: Examine repository changes and build configurations for unauthorized modifications, including unexpected Docker image changes or cryptocurrency-mining components.
  8. Restrict workflow permissions: Apply least-privilege permissions to GitHub Actions, review third-party actions, and protect important branches with appropriate approval requirements.
  9. Check package publishing activity: Review npm, PyPI, DockerHub, and other registry accounts for unauthorized releases or changes.

Organizations should prioritize rotating credentials over simply deleting the malicious workflow. Once a secret has been exposed, removing the code that collected it does not invalidate the credential.

Key Takeaway

The renewed GhostAction campaign demonstrates how compromised developer accounts and seemingly legitimate CI/CD workflows can become tools for large-scale credential theft.

By exploiting trust in open-source maintainers and searching both current repository files and historical commits, attackers can potentially collect credentials that developers believe they have already removed.

Developers should audit their repositories and GitHub Actions workflows, revoke potentially compromised credentials, rotate exposed secrets, and investigate forks and downstream mirrors to prevent continued access.