A Known Campaign Just Had Its Biggest Spike Yet
GhostAction is not a new threat, researchers first observed the credential-theft campaign in September 2025, but it spiked sharply again on October 8 and 9, 2026. In that window, the campaign compromised roughly 1,900 GitHub accounts and pushed malicious GitHub Actions workflows into more than 30,000 repositories spanning approximately 3,000 users and organizations. That scale, tens of thousands of repositories touched in a two-day window, puts GhostAction among the more consequential supply-chain credential campaigns to hit GitHub this year.
The fact that this is a resurgence of a known campaign rather than a brand-new attack changes how a reader should think about it. A thirteen-month-old campaign that is still spiking, and still working, is a signal that the underlying technique, abusing GitHub Actions workflows to exfiltrate secrets, remains effective against the current state of most organizations' CI/CD defenses. That persistence is arguably more concerning than a flashy new zero-day, because it means the fix has been available and simply has not been widely adopted.
The Malicious Workflows Were Built to Blend In
GhostAction's method centers on pushing malicious GitHub Actions workflow files into compromised repositories, disguised under innocuous-sounding names such as security-audit.yml. A file named to look like a routine security check is a deliberate choice: it is exactly the kind of workflow a developer skimming a repository's Actions tab would assume is legitimate, or even reassuring, rather than pause to scrutinize. That naming convention is a small but effective piece of social engineering aimed at the people reviewing CI/CD configuration, not just at automated scanners.
Once such a workflow runs inside a compromised repository's CI pipeline, it operates with whatever access that pipeline already has, which in most real-world setups includes secrets injected as environment variables for deployment, testing or integration purposes. That is the structural weakness GhostAction exploits: CI/CD pipelines are, by design, trusted with broad access to an organization's secrets, and a malicious workflow slipped into that pipeline inherits that trust automatically rather than having to earn it through a separate exploit.
What the Attackers Were After, and What They Got
GitGuardian researchers Gaetan Ferry and Guillaume Valadon found that the attackers extracted 3,174 secrets specifically from public repositories' CI pipelines during this campaign. The categories targeted were broad: CI/CD secrets, cloud credentials, package-registry tokens, and AI provider API keys. That last category is a telling addition to the target list, it shows credential thieves now actively hunt for AI provider keys inside CI/CD pipelines with the same priority they give traditional cloud credentials.
A haul of 3,174 secrets from public repositories alone, with private-repository exposure likely uncounted in that figure, represents a substantial amount of downstream access an organization now has to assume is compromised. Each of those secret types carries a different blast radius: a cloud credential can mean direct infrastructure access, a package-registry token can mean the ability to publish malicious packages under a trusted name, and an AI provider key carries the billing and data-access risk now familiar from other incidents in this space.
The Entry Point Was Stolen Credentials, Not a GitHub Flaw
GitGuardian's research indicates the attackers gained their initial access using stolen Personal Access Tokens or credentials harvested from infostealer logs, rather than through any vulnerability in GitHub's platform itself. That distinction matters for where defensive attention should go: this is fundamentally a credential-hygiene problem, tokens that leaked somewhere else and were never revoked, rather than a patchable software bug that GitHub needs to fix on its end, which also means there is no single vendor patch that makes this campaign stop working against a given organization.
Infostealer logs in particular have become a reliable initial-access market for campaigns like this one. Malware that harvests browser-saved credentials, session tokens and personal access tokens from infected developer machines feeds a steady supply of valid GitHub access into underground markets, and GhostAction's operators appear to be regular buyers or users of exactly that supply. Reducing exposure to this specific campaign starts with reducing how many of your developers' machines are running infostealer malware in the first place.
The Most Alarming Finding Is About Repeat Victims
Perhaps the most important detail in GitGuardian's research is that some organizations were compromised repeatedly, across the September 2025 wave, an August 2026 wave, and this October 2026 spike, because they never rotated the secrets stolen in the earlier incidents. Researchers also noted this latest wave seems more experimental and manual than previous ones, suggesting the operators are still iterating on technique even as they revisit the same unrotated credentials at some victims.
That repeat-victim pattern is damning in a specific, actionable way: it means detection was not the failure for those organizations, the campaign had already been publicly reported after its earlier waves, but remediation was. Knowing you were breached and rotating the exposed secret are two different steps, and this research shows a meaningful number of organizations completed only the first one, leaving the same stolen keys valid for attackers to use again more than a year later.
The CI/CD Secret Hygiene Question Every Engineering Leader Should Answer This Week
GhostAction is a useful forcing function for a question every engineering organization should be able to answer with confidence: when a secret used in your CI/CD pipeline is exposed, is there a defined, automatic process that rotates it, or does rotation depend on someone remembering to do it manually after reading a security advisory? The repeat-victim finding here suggests that for a meaningful number of organizations, the honest answer is the latter, and that gap is now a documented, exploited pattern rather than a theoretical risk.
Concrete steps worth taking this week: audit which GitHub Actions workflows in your repositories have access to production secrets and confirm each one is reviewed, not just assumed safe because it has run before; set short expiration windows on Personal Access Tokens rather than issuing long-lived ones; and build automatic secret rotation into your incident response playbook so that exposure triggers a system action, not a to-do item that can get missed during the next fire drill.
