Date Observed: October 8-16, 2026 (latest two waves; campaign remains active)
Ecosystem: GitHub, GitHub Actions, and developer workstations
Targets: Open-source maintainers; CI/CD secrets; cloud, package-publishing, and AI API credentials
Attack Type: Compromised maintainer accounts, malicious GitHub Actions workflow injection, credential theft, and developer-workstation persistence
Impact: More than 30,000 repositories targeted; about 1,900 GitHub user accounts compromised; 3,174 CI secrets targeted for extraction; second-stage stealer found in 94 repositories

Key Takeaways

  • Between October 8 and 12, GhostAction’s workflow wave targeted more than 30,000 repositories across roughly 3,000 GitHub users and organizations, using about 1,900 compromised user accounts. A separate developer-workstation second stage followed on October 15–16.
  • Attackers pushed fake “security audit” workflows directly into repositories using compromised maintainer identities, then triggered them to steal GitHub Actions secrets and credentials from the working tree and full git history.
  • The October variant searched for AWS, GitHub, GitLab, OpenAI, Anthropic, and other credentials and exfiltrated findings over plain HTTP to 193.32.204.199.
  • As GitHub began blocking the known malicious workflow, the operators added a second stage — found in 94 repositories — that does not depend on GitHub executing anything: it runs on a developer workstation through VS Code and, on macOS and Linux, persists with a cron job.
  • Deleting the malicious workflow is not enough. Organizations should revoke the compromised GitHub access, rotate exposed credentials, inspect full repository history, and investigate outbound traffic from CI runners and developer systems.

Introduction

GhostAction, a GitHub Actions credential-theft campaign first documented in 2025, has escalated sharply. GitGuardian reports that between October 8 and 12, 2026, the threat actor targeted more than 30,000 public repositories across about 3,000 users and organizations. The activity relied on roughly 1,900 GitHub accounts to reach that 30,000-repository, 3,000-owner target surface, and attempted to extract 3,174 secrets from public repositories’ CI environments.

This is not simply another repository compromise. GhostAction turns trusted maintainer access and trusted CI automation into a credential theft and exfiltration channel. The attacker inserts a workflow that looks like a security audit, waits for GitHub Actions to run it, and uses the build environment itself to collect and transmit secrets. The latest phase goes further, adding developer-workstation execution that can survive even after the malicious workflow is removed.

Scope and Impact of the Attack

The current outbreak is the latest phase of an ongoing campaign that first appeared in 2025 and was never fully neutralized. GitGuardian traced 772 public repositories across 373 users and organizations during August and September 2026, targeting 2,577 secrets. The October wave was much larger: more than 30,000 repositories were targeted in several bursts, including a batch of more than 29,000 repositories on October 8.

Socket Research initially documented an October 8 burst in which compromised maintainer accounts pushed a workflow named security-audit.yml into hundreds of repositories, including kitao/pyxel and uber/athenadriver. The workflow combined theft of configured GitHub Actions secrets with a new scan of the repository working tree and full git history for cloud, source-control, and AI-service credentials.

GitHub began preventing the known malicious workflows from running on October 9, according to subsequent campaign tracking. That stopped the later October 10 and 12 batches from successfully extracting secrets through the same workflow, and the attacker then changed tactics. One caveat on the numbers: they describe what the campaign targeted, not what it is confirmed to have stolen. GitHub’s run-approval gating limited actual theft in earlier waves — in August and September, GitGuardian found most workflow runs were held for approval and only a fraction actually executed. The 30,000-repository and 3,174-secret figures should be read as attack surface, not an actual breach count.

How the Attack Works

Stage 0: Compromise maintainer access

GhostAction depends on valid GitHub access that can modify repositories. The exact initial-access method for every compromised maintainer is not established. Researchers have since documented GhostAction-linked phishing infrastructure designed to steal GitHub credentials and authorize an OAuth application with repository and workflow permissions, but that infrastructure has not been tied to every affected account. Once an account is compromised, the attacker can act under a trusted maintainer identity.

Stage 1: Inject a malicious GitHub Actions workflow

Using the compromised account, the attacker pushes a new or modified workflow directly into repositories the account can write to. Filenames observed across the campaign include github_actions_security.yml, security-check.yml, and security-audit.yml. Commit messages such as “Add security audit workflow” make the change look routine. Because the commit is made with the victim’s own identity, the malicious workflow can appear to be an authorized repository change.

The workflow is configured to run on push or by manual dispatch. In the October variant, actions/checkout is used with full history enabled, allowing the job to inspect not only current files but previous commits and branches.

Stage 2: Harvest CI/CD and historical credentials

The malicious job collects available GitHub Actions secrets and scans the checked-out repository for credential patterns. It also runs git log -p –all to search full Git history, which means removing a credential from the current source tree is not sufficient to neutralize the threat. Credentials can still be recovered from prior commits and abused if they have not been revoked or rotated. Patterns searched for by the exploit include AWS access keys, GitHub and GitLab tokens, cloud credentials, package-publishing tokens, and API keys for AI services such as OpenAI and Anthropic.

StepSecurity and Socket both observed the payload sending collected data to the hard-coded IP address 193.32.204.199. The primary October workflow transmitted the data over plain HTTP, making the runner’s outbound connection the final step between credential access and credential loss.

Stage 3: Move from CI runners to developer workstations

On October 16, OpenSourceMalware reported a second stage that had landed in 94 compromised repositories belonging to 66 owners. Rather than relying on GitHub to run a workflow — the step GitHub had started blocking — this stage shifts execution onto the developer’s machine.

The attacker added a VS Code tasks.json file and a fake font file, public/fonts/fa-solid-400.woff2, that actually contains JavaScript. When the project is opened in VS Code in a trusted workspace with automatic tasks enabled, the task runs the fake font file with Node.js, executing the payload on the developer’s machine and, on macOS and Linux, installing a cron job that polls the attacker’s server every five minutes. In a hardened setup — an untrusted workspace, or automatic tasks disabled — the task does not auto-run, so this stage is not zero-click.

The new stage also includes a second GitHub Actions workflow as a fallback. If direct exfiltration fails, the workflow can use GitHub itself to store stolen findings in a secret Gist. This is an important change: blocking a known malicious IP or workflow filename does not eliminate the attack if the adversary can shift to a trusted destination or move execution onto the developer workstation.

Researchers note the second-stage technique — a fake font file paired with a VS Code tasks.json auto-run — copies tradecraft previously seen in the North Korean-linked PolinRider campaign. OpenSourceMalware attributes this new stage to GhostAction based in part on its use of GhostAction infrastructure, but found no shared indicators connecting GhostAction itself to PolinRider or other DPRK malware. GitGuardian separately cautions that the GitHub credentials used in these injections are traded and reused by multiple unrelated actors, so not all activity in affected repositories necessarily traces to a single operator.

Persistence and Reinfection

GhostAction also demonstrates why repository cleanup must include the credential that enabled the compromise. GitGuardian found cases where workflows implanted in earlier waves were simply updated to point to new exfiltration infrastructure. OpenSourceMalware identified repositories where maintainers removed the first malicious workflow, but the attacker returned days later with the second stage because the underlying access apparently remained valid.

Why This Matters to DevOps and DevSecOps Teams

GhostAction attacks the trust model around CI/CD rather than exploiting a single vulnerable package. A valid maintainer identity writes a workflow into a legitimate repository, and the workflow executes inside GitHub’s own automation environment with access to whatever secrets and credentials the job can reach. The attacker does not need to defeat secret masking if the workflow itself can reference or discover the credential and send it off the runner.

The full-history search also expands the incident-response scope. Removing a credential from source control is not remediation if the credential remains valid in an older commit. And the new workstation stage means the same repository compromise can move from CI/CD into the developer environment, where endpoint and identity controls become equally important.

Why Workflow Cleanup and Secret Scanning Aren’t Enough

Deleting the malicious workflow removes the visible payload but does not revoke the maintainer credential, session, token, or OAuth access that allowed it to be written. Rotating only the secrets currently configured in GitHub Actions can also miss credentials that remain valid in Git history. Meanwhile, static secret scanning can identify exposed credentials in source, but it does not by itself prevent a running CI job from transmitting live secrets or API tokens that are legitimately available to the workflow.

GitHub’s intervention shows the value of platform-level detection: known GhostAction workflow runs were stopped. But the campaign quickly changed filenames, ports, markers, and execution paths, then added a developer-workstation stage. The defensive lesson is to combine identity and repository protections with controls that govern what a running build is allowed to communicate and do.

How InvisiRisk Protects Against This Attack

The InvisiRisk Build Application Firewall (BAF) operates inline with CI/CD traffic and enforces policy while a build is running. GhostAction’s initial maintainer-account compromise and direct repository modification can occur outside the build, so those stages still require strong GitHub identity, branch-protection, and endpoint controls. Once the malicious workflow executes inside a protected CI/CD environment, however, InvisiRisk can interrupt the exfiltration stage that turns access into a breach.

Block unauthorized outbound connections. The GhostAction workflow sends stolen data to 193.32.204.199, an external raw IP that a normal build has little reason to contact. InvisiRisk can enforce destination policies on build traffic and block unauthorized outbound connections before the data leaves the runner. The same policy model continues to apply if the attacker changes to another unapproved endpoint.

Detect and block credential exfiltration. InvisiRisk performs protocol-aware inspection of build-time network traffic and can detect secrets and credentials leaving the build environment. In the primary GhostAction workflow, the payload sends the stolen material over HTTP, making the exfiltration visible at the exact point where the malicious job tries to move it off the runner.

Block unauthorized GitHub API actions. The latest GhostAction stage adds a GitHub-based fallback that can place stolen findings in a secret Gist. A simple domain allowlist may permit api.github.com because legitimate builds use it. InvisiRisk can enforce policy at the API-action level, allowing expected GitHub operations while blocking out-of-scope write actions used for exfiltration.

The workstation component found in the latest GhostAction phase is outside the CI/CD boundary of the BAF and should be addressed with endpoint and identity controls. The attack is therefore a good example of layered security: protect maintainer identities and developer machines, and separately enforce what code is allowed to do when it executes inside the build.

Why Build-Time Defenses Matter

GhostAction does not need a malicious dependency to steal CI/CD credentials. It turns the workflow itself into the malware. Once the injected job runs, it has access to trusted automation, repository history, configured secrets, and outbound network connectivity before post-build scanners have anything to inspect.

Build-time enforcement closes that gap. Restricting outbound destinations, inspecting data leaving the runner, and controlling GitHub API actions can contain the CI/CD phase even when an attacker has already obtained valid repository access. Identity, branch protection, secret scanning, and endpoint security remain essential, but they do not replace real-time controls at the point where the malicious workflow actually executes.