GhostAction Hits 30,000 GitHub Repos: How to Find Rogue Actions Workflows and Rotate Exposed Secrets

That exact scenario played out at massive scale in October 2026. According to reporting by SC Media and The Hacker News, citing primary security research from GitGuardian and Socket, the supply chain credential-theft campaign known as GhostAction escalated dramatically between October 8 and October 12, 2026. By hijacking approximately 1,900 legitimate GitHub user accounts, the threat actors targeted more than 30,000 repositories across 3,000 users and organizations, attempting to extract 3,174 secrets from public repositories' CI/CD workflows alone.

Even more concerning than the sheer volume of targeted repositories is how the payload evolved. Rather than merely siphoning off GitHub Actions environment secrets, the October wave introduced automated secret scanning across full repository working trees and Git commit histories, hunting for AWS keys, GitHub and GitLab tokens, package registry credentials, and AI provider API keys.

GhostAction Campaign Scale: Targeted Repos vs. Executed Runs​

Before panic sets in, it is crucial for IT and DevSecOps teams to separate the blast radius of targeted repositories from confirmed credential exfiltration. In supply chain incidents, headline numbers can easily blur the line between an injected file and a successful theft.

GitGuardian’s October 13, 2026 analysis by researchers Gaetan Ferry and Guillaume Valadon tracked the campaign's acceleration between October 8 and October 12, noting that the largest spike occurred on October 8 and 9. Across the entire October burst, GitGuardian's dataset recorded:

• More than 30,000 repositories targeted across roughly 3,000 users and organizations.
• Approximately 1,900 compromised GitHub accounts used to perform the unauthorized commits.
• 3,174 CI secrets targeted for extraction across public repositories.

Why is the distinction between "attempted to extract" and "stole" so important? Because injecting a workflow file does not always guarantee that the workflow executed or that the secrets were valid. Furthermore, GitGuardian documented that GitHub began actively blocking the malicious workflows from running starting on October 9, 2026.

GitGuardian broke the October wave down into eight distinct operational batches, tracked via HTTP query parameters appended to the attacker's exfiltration server (193.32.204.199):

(Note: Commit counts reflect batch-level commits observed by GitGuardian, as some repositories were hit multiple times across evolving payload versions.)

While GitHub's intervention on October 9 neutralized the October 10 (mnsft) and October 12 (security) batches before they could run, the six batches deployed on October 8 did execute. Separate research published by Socket on October 9—which examined an initial subset of 346 repositories compromised via two maintainer accounts (henrywoo and kitao) before later identifying over 500 accounts committing workflows to tens of thousands of repos since October 7—confirmed that the injected workflows ran and exfiltrated data in affected repositories, including the 18,420-star kitao/pyxel project and the Uber-owned uber/athenadriver repository. However, as of its October 9 report, Socket noted that no malicious package releases had been observed on PyPI or crates.io resulting from those stolen publishing tokens.

Section Summary: While over 30,000 repositories received malicious commits in October 2026, actual exposure depends on whether the workflow executed before GitHub's October 9 block took effect. However, thousands of commits on October 8 did execute, making thorough log auditing mandatory.

Anatomy of the Attack: How GhostAction Hijacks GitHub Actions​

How does an attacker convince 1,900 developer accounts to suddenly commit malware to their own projects? They don't use zero-day exploits against GitHub's core infrastructure; they walk through the front door using valid keys.

According to The Hacker News and GitGuardian, the threat actors gain repository write access using stolen Personal Access Tokens (PATs) or credentials harvested from infostealer malware logs and historical credential dumps. Once an attacker holds a valid token for a developer account, they automate the enumeration of every repository that identity can write to—including personal projects, dormant forks, and organization-owned repositories where the user has maintainer privileges.

Phase 1: Reconnaissance and Workflow Injection​

In traditional GhostAction waves (first uncovered by GitGuardian in September 2025, when 817 public repositories were compromised and at least 3,325 secrets were exfiltrated, followed by a late-summer wave between August 31 and September 30, 2026, that hit 772 repositories across 373 users and organizations), the attacker's automation first scans the target repository's existing .github/workflows files. It looks for references to ${{ secrets.SECRET_NAME }} to build a custom shopping list of secret variables already configured in that repository's GitHub Actions settings.

Next, the attacker commits a deceptive workflow file directly to the repository. Depending on the wave, these files wear harmless-looking compliance names:

• .github/workflows/security-audit.yml (Commit messages: Add security audit workflow or Update security audit workflow)
• .github/workflows/github_actions_security.yml (Commit messages: Add Github Actions Security workflow or Update Github Actions Security workflow)
• .github/workflows/security-check.yml (Commit message: Add security check workflow, observed in a smaller September 7 variant that reported to port 3000 with unique injection IDs)

Phase 2: The Evolving October 2026 Payload (v1 to v3)​

What made the October 8–9 escalation so dangerous was a two-pronged collection mechanism documented by both GitGuardian and Socket. In addition to dumping named GitHub Actions secrets, the attackers upgraded the workflow to checkout the repository with fetch-depth: 0—pulling every branch, tag, and historical commit—and run regular expression sweeps across both the live working tree and the entire Git commit history.

Why scan repository files if a repo is public? As GitGuardian pointed out, scanning public files inside a GitHub Action makes little sense if an attacker could just clone the public repo externally; including this step proves the tooling was engineered to pillage private repositories and unreachable commit histories reachable by the compromised maintainer tokens.

GitGuardian tracked three rapid iterations of this payload on October 8:

1. Payload v1 (Deployed to ~1,800 repositories): Introduced fetch-depth: 0 and scanned working files (grep -rEho) and Git history (git log -p --all) using detection regexes covering AWS keys, GitHub/GitLab PATs, AI API keys, and cloud tokens, posting the haul via HTTP curl to [url]http://193.32.204.199/?c=bling[/url].
2. Payload v2 (Deployed to ~100 previously targeted repositories): Switched the regex matching to case-insensitive (-i) and realized a critical operational flaw in v1: stealing a 20-character AWS Access Key ID (AKIA... or ASIA...) is useless without the matching 40-character Secret Access Key. Version 2 added a context pass (grep -rEi -B2 -A2) that grabs two lines above and below every AWS Key ID match in the working tree, wrapping the output in AKIA_CTX_START and AKIA_CTX_END markers.
3. Payload v3 (Deployed to 160 previous victims, then 20 minutes later to ~28,000 new repositories): Added the two-line AWS context window (hctx) to the git log -p --all history scan (reading up to 200,000 lines of raw patch history), ensuring that even if a developer accidentally committed an .env or Terraform file years ago and deleted it in the next commit, the workflow would reconstruct the complete AWS key pair from the Git reflog and send it out.

What the Regex Sweep Hunts For​

Socket’s technical breakdown of the v3 monami payload injected into kitao/pyxel identified 13 specific credential patterns hardcoded into the scanner:

• AWS Credentials: Long-term access key IDs (AKIA[0-9A-Z]{16}), STS temporary access key IDs (ASIA[0-9A-Z]{16}), 40-character secret access keys, and STS session tokens.
• AI Service API Keys: Anthropic API keys (sk-ant-...), OpenAI project keys (sk-proj-...), and OpenRouter keys (sk-or-...).
• Source Control Tokens: GitHub classic PATs (ghp_...), GitHub fine-grained PATs (github_pat_...), and GitLab PATs (glpat-...).
• Cloud & SaaS API Keys: Google Cloud / Firebase API keys (AIza...), Slack tokens (xox[baprs]-...), and SendGrid mail API keys (SG\....).

Section Summary: The October GhostAction payload acts as a dual-threat harvester. It extracts configured CI/CD publishing secrets (like PYPI_PASSWORD, CARGO_REGISTRY_TOKEN, Azure credentials, and SSH keys) while simultaneously digging through current files and deleted Git commit histories for cloud and AI keys.

The Unrotated Secret Problem: Why Victims Keep Getting Hit​

If there is one sobering takeaway for enterprise security teams in GitGuardian’s report, it is the persistence of unrotated credentials. When GitGuardian cross-referenced the victims of the October 2026 surge against earlier waves from September 2025 and August–September 2026, they discovered that a subset of victims had been compromised in previous waves.

Even worse, during the August–September 2026 wave, GitGuardian found 92 repositories where the attacker did not even need to inject a new workflow file. Instead, they pushed a commit titled Update Github Actions Security workflow that simply modified the malicious workflow left behind in September 2025, updating the old exfiltration domains (bold-dhawan.45-139-104-115.plesk.page, carte-avantage.com, or 170.39.218.2) to point to the new 193.32.204.199 server. By October 5, 2026, only 124 repositories (16%) from the August–September wave had been cleaned up in public history.

GitGuardian also highlighted how leaked developer credentials rarely belong to a single threat actor. When investigating the August–September wave, researchers found that a compromised maintainer account for the popular 6,000-star project kuafuai/DevOpsGPT was used on August 30, 2026, to slip an XMRig 6.21.0 Monero cryptominer into the project's Docker image under a commit disguised as an OpenAI version update, followed on September 15 by a GhostAction workflow injection targeting DockerHub credentials. Across their dataset, GitGuardian found 13 GhostAction victim repositories that were also abused by at least four separate cryptomining campaigns.

Why does this happen? Because infostealer logs and credential dumps are bought, sold, and traded across cybercrime forums. If a Windows developer's workstation is hit by an infostealer that grabs browser cookies or an unencrypted .git-credentials or .npmrc file, or if a long-lived GitHub PAT is leaked in a public repo, multiple threat groups will eventually run that token through automated exploitation scripts.

Step-by-Step Remediation Guide for Developers and IT Admins​

Deleting a rogue .yml file and calling it a day is the cybersecurity equivalent of taking the batteries out of a chirping smoke alarm. Because GhostAction exploits both identity access and deep Git history, remediation requires a methodical cleanup.

1. Hunt for Indicators of Compromise (IoCs)​

Audit your organization's GitHub audit logs, repository commit histories, and egress firewall logs (especially if you run self-hosted GitHub Actions runners on Windows Server or Linux VMs) for the following artifacts:

• Suspicious Workflow Paths:
  • .github/workflows/security-audit.yml
  • .github/workflows/github_actions_security.yml
  • .github/workflows/security-check.yml
• Suspicious Commit Messages:
  • Add security audit workflow / Update security audit workflow
  • Add Github Actions Security workflow / Update Github Actions Security workflow
  • Add security check workflow
• Network Exfiltration Endpoints:
  • 193.32.204.199 (Including HTTP requests with query strings like ?c=bling, ?c=blingnew, ?c=monami, ?c=new, ?c=mnsft, ?c=security, or port 3000/api/workflow/receive?inj=)
  • Historical GhostAction endpoints: 170.39.218.2, bold-dhawan.45-139-104-115.plesk.page, objective-hopper.45-139-104-115.plesk.page, and carte-avantage.com
• Payload Markers in Logs:
  • AKIA_CTX_START and AKIA_CTX_END

2. Revoke the Entry Vector (The Compromised Identity)​

Remember that the malicious workflow did not magically appear—a developer or maintainer account with write permissions pushed it.

• Identify which GitHub user account authored or committed the rogue workflow.
• Immediately revoke all Personal Access Tokens (classic and fine-grained), OAuth app authorizations, active web sessions, and SSH keys associated with that user.
• Enforce phishing-resistant Multi-Factor Authentication (MFA/FIDO2 passkeys) and scan the developer's local workstation for infostealer malware before issuing new credentials.
• Audit every repository and organization that the compromised account had write access to—do not assume the attacker only hit one repo.

3. Rotate Both CI/CD Secrets and Historical Git Secrets​

If the workflow file was injected, inspect its contents before deleting it, and check the Actions tab to see if the workflow ever executed.

• Set A (GitHub Actions Secrets): Look at the run: block in the injected YAML file. Every ${{ secrets.NAME }} listed there was targeted. If the workflow ran, consider all of those credentials compromised. Rotate your cloud deployment keys (AWS, Azure, GCP), database passwords, SSH keys, and package registry tokens (PyPI, npm, crates.io, DockerHub), and verify that no unauthorized package versions or container images were published during the exposure window.
• Set B (Git History Secrets): Because the October payload runs git log -p --all with fetch-depth: 0, rotating only your current GitHub Actions secrets is not enough. Run a full secret scan across your entire repository history, including stale branches and tags (git log -p --all). Any AWS key, Anthropic/OpenAI key, Slack token, or GitHub PAT that ever appeared in a commit must be revoked and rotated. For AWS keys found in history, review AWS CloudTrail logs for unauthorized IAM creation or compute usage.

4. Harden Your GitHub Organization Against Future Waves​

To prevent stolen credentials from turning into silent CI/CD compromises in the future:

• Eliminate Long-Lived PATs: Migrate away from classic Personal Access Tokens wherever possible. Use fine-grained PATs with strict expiration dates and minimum repository scope, or enforce SAML Single Sign-On (SSO) with Microsoft Entra ID or your identity provider so tokens require active SSO authorization.
• Adopt OIDC for Cloud Deployments: Stop storing static AWS (AKIA...), Azure, or GCP credentials in GitHub Actions secrets. Use OpenID Connect (OIDC) federated identity so GitHub Actions workflows request short-lived, dynamically scoped tokens directly from your cloud provider at runtime.
• Enable Secret Scanning and Push Protection: Turn on GitHub Secret Scanning and Push Protection across your repositories to block developers from accidentally committing cloud or AI keys into Git history in the first place.
• Monitor Forks and Workflow Approvals: If you fork open-source projects (especially in the Python, Rust, or AI/ML ecosystems hit during this wave), inspect .github/workflows/ before enabling Actions on your fork.

The GhostAction escalation is a textbook reminder that in modern DevOps, identity security and source-code hygiene are inseparable. When a single unrotated token can automatically weaponize thousands of repositories in minutes, locking down your developer credentials and purging secrets from your Git history isn't just best practice—it's survival.