GhostAction: How a Credential-Theft Campaign Compromised 1,900 GitHub Accounts

On October 8 and 9, 2026, GitGuardian's security researchers detected a sharp spike in malicious GitHub activity linked to the GhostAction campaign. The attackers had already compromised approximately 1,900 user accounts across 3,000 distinct organizations and users. What made this campaign particularly dangerous was its precision: the threat actors systematically targeted 30,000 repositories to extract CI/CD secrets, credentials and API tokens embedded in build pipelines and configuration files. The scale and coordination suggested either a stolen account database, credential stuffing from prior breaches, or exploitation of a GitHub API vulnerability. GitGuardian's analysis indicated that the attackers had already been active before the October spike, but the campaign intensified significantly over those two days.

Unlike attacks that focus on stealing source code itself, GhostAction's strategy targeted the secrets stored in CI/CD pipelines. These secrets are the keys to the kingdom: authentication tokens for deployment services, database passwords, third-party API credentials, and signing keys used to build and release software. When a developer commits code to a repository linked to GitHub Actions or similar CI platforms, those credentials often live in environment variables or encrypted storage within the build system. The attackers attempted to extract 3,174 secrets from public repositories, meaning they likely inserted malicious code or modified workflows to log or exfiltrate these values. Once they possessed a valid API token or database credential from a compromised account, they could impersonate that user, modify repository settings, inject malware into releases, or pivot to the internal systems the tokens gave them access to.

The fact that they targeted public repositories is telling: public repos are easy to enumerate and monitor, and their workflows are visible to anyone with a GitHub account. An attacker scanning thousands of public repositories can identify which ones use CI/CD systems and which ones might contain valuable secrets in their logs or configuration.

GitHub accounts are a form of software supply-chain infrastructure. When you compromise a developer's account, you don't just gain access to their private projects; you gain trust within their organization and the ability to influence code that gets shipped to customers. A malicious commit pushed from a trusted internal account is far harder to detect than code from a stranger. Enterprise customers and open-source projects alike trust the developers who have write access to repositories. If an attacker can commit code as that user, CI/CD pipelines will build and test it without question. This is exactly why supply-chain attacks—compromising dependencies or build systems rather than end-user software—have become increasingly valuable to sophisticated threat actors. GhostAction's approach of stealing developer secrets and then using them to extract further credentials represents a multi-stage supply-chain intrusion.

The root cause of the GhostAction campaign was likely one of two scenarios. The first is credential stuffing: the attackers obtained username and password pairs from previous data breaches (Linkedin, Twitter, other sites developers use) and ran them against GitHub's login endpoint. Many developers reuse passwords across sites, so a single breached database can yield hundreds of working GitHub credentials. The second scenario, less common but more damaging, would be exploitation of a GitHub API flaw or a supply-chain attack on a third-party GitHub app that many developers use. GitGuardian did not disclose the initial compromise vector, which is typical in these reports to avoid giving attackers a roadmap. Regardless of how the accounts were taken, the speed and scale of the October 8-9 spike suggests the attackers had a list of compromised credentials and deployed automation to harvest secrets from as many repositories as possible before detection.

If you use GitHub, particularly if you maintain repositories with CI/CD pipelines, take these steps:

1. Enable two-factor authentication (2FA) on your GitHub account using a hardware security key or an authenticator app; SMS-based 2FA is better than nothing but weaker than app-based or hardware methods.

1. Review your personal access tokens and deploy keys in Settings > Developer settings; revoke any tokens you do not recognize or have not used recently.

1. Rotate secrets stored in your CI/CD environment: database passwords, API keys, signing certificates, and authentication tokens used by GitHub Actions or other build systems.

1. Check your GitHub account's Security Log (under Settings > Security) to see if there have been unusual sign-in attempts or changes to your repositories and settings.

1. If you maintain public repositories with CI/CD workflows, audit those workflows to ensure they do not log secrets or pass them insecurely to external services.

1. Use GitHub's secret scanning feature, which alerts you if any credentials are committed to your repository; configure it to block commits containing detected secrets.

1. Consider using short-lived tokens and role-based access control (RBAC) in your CI/CD platform so that each job has only the permissions it needs.

Supply-chain attacks like GhostAction succeed because developer credentials are simultaneously valuable and difficult to protect at scale. A single compromised account can affect hundreds of downstream users and projects. Organizations investing heavily in endpoint security and perimeter defenses often overlook the risk that a developer's workstation or account could become a pivot point for attackers. The GhostAction campaign also illustrates why organizations should not treat CI/CD secrets with the same trust they treat packaged, released software. Secrets in build pipelines are an internal, operational asset—more fragile and harder to audit than code that ships in a release. Finally, the campaign shows that automation and speed matter to attackers: the October spike lasted only hours, suggesting the threat actors had pre-staged their tooling and were running harvesting scripts at scale against thousands of targets simultaneously. This is the hallmark of a well-organized, resource-rich group or a commercial service renting compromised credentials.

For development teams, the GhostAction incident should trigger a fresh conversation about who has write access to production repositories, how credentials are managed in CI systems, and what happens if a developer account is compromised. For security teams in larger organizations, it reinforces the need to monitor GitHub audit logs, detect unusual repository modifications, and implement controls that prevent a single compromised account from modifying critical deployment pipelines. For open-source maintainers, it underscores the importance of requiring code review before merge, using branch protection rules, and verifying the identity of contributors—especially if a trusted contributor's account suddenly begins submitting unusual changes. The incident also highlights why tools like SBOM (software bill of materials) generation and dependency scanning matter: if a malicious package does make it into a release, you want to know which customers are affected and how quickly you can patch them.

What is GhostAction and who is behind it?

GhostAction is a credential-theft campaign identified by GitGuardian in October 2026 targeting GitHub accounts. The threat actors' identity and motivation have not been publicly disclosed, though the sophistication and scale suggest either a commercial threat-for-hire service or a state-sponsored group interested in supply-chain intelligence.

How do I know if my GitHub account was compromised in this attack?

GitHub has not released a public list of affected users. Check your Security Log for unusual sign-in attempts or unexpected changes to repositories. If you noticed any commits you did not make or settings changes, enable 2FA immediately, change your password, and contact GitHub support.

What are CI/CD secrets and why do attackers want them?

CI/CD secrets are authentication tokens, API keys, and credentials used by build systems to deploy code and access infrastructure. Attackers want them because they provide legitimate access to production systems, deployment services, and downstream infrastructure, enabling lateral movement and persistence.

Should I store secrets in my GitHub repository?

No. GitHub's secret scanning feature will alert you if a secret is committed, but the best practice is to never commit secrets at all. Use GitHub's built-in secrets storage in repository settings or GitHub Actions, or integrate with a dedicated secret management tool like HashiCorp Vault or AWS Secrets Manager.

Is two-factor authentication enough to prevent my account being compromised?

Two-factor authentication significantly reduces risk, especially when using hardware keys or app-based authentication. However, it is not perfect: attackers can sometimes intercept OTP codes, compromise the app itself, or use phishing to trick users into revealing their 2FA codes. Combined with strong, unique passwords and regular monitoring of account activity, it is the strongest defense available to individual users.

Source: The Hacker News