GitHub accounts hijacked in GhostAction campaign hit 30,000 repositories

Credential-stealing workflows targeted CI/CD secrets and AI provider API keys

By LineZotpaper

Published16 October 2026

Read Time3 min

Hackers compromised roughly 1,900 GitHub accounts and used them to inject credential-stealing workflows into more than 30,000 repositories, according to security firms tracking the GhostAction campaign. The malicious GitHub Actions jobs targeted CI/CD secrets, cloud access keys and API keys belonging to AI providers including Anthropic, OpenAI and OpenRouter.

Security researchers have detailed a large-scale supply chain attack on GitHub, in which attackers accessed about 1,900 developer accounts and used them to modify workflows directly in more than 30,000 repositories.

The campaign, tracked as GhostAction by GitGuardian, intensified on October 8 and 9, when attackers reached repositories belonging to roughly 3,000 users and organizations and attempted to extract 3,174 secrets. Unlike the earlier tj-actions/changed-files compromise, which poisoned a shared Action used by thousands of repositories, GhostAction worked by using stolen developer credentials to alter workflows directly, with no vulnerability in GitHub Actions itself.

It remains unclear how the attackers obtained the credentials. StepSecurity's October 9 analysis points to personal access tokens pulled from credential dumps as the likely source, though the initial compromise has not been confirmed.

With access to repositories, the attackers added disguised workflows under names such as security-audit.yml or github_actions_security.yml. Because the files referenced secrets already used by legitimate builds, the malicious jobs could collect those credentials when they ran and send them to an attacker-controlled server at 193.32.204.199.

The October variant went further than secrets explicitly referenced by workflows, using actions/checkout@v4 with fetch-depth: 0 to scan the working tree and full Git history for AWS keys, GitHub and GitLab personal access tokens, Google and Firebase keys, and API tokens from Anthropic, OpenAI and OpenRouter. Later versions captured surrounding lines to pair AWS key IDs with their corresponding secret access keys. This meant keys removed from the current codebase but still present in Git history were also harvested.

"This payload was deployed in multiple phases," GitGuardian wrote, describing an initial push to about 160 previously targeted victims and, 20 minutes later, a far larger deployment into 28,000 new repositories across October 8 and 9.

The total number of stolen credentials remains unknown. GitGuardian counted 3,174 secrets targeted for extraction and confirmed some exfiltration during the October campaign, but did not determine how many distinct credentials reached the attackers.

During the August and September campaign, GitGuardian identified malicious workflows in 772 public repositories across 373 users and organizations. Of the 3,669 workflow runs recorded across 605 repositories, only 499 executed, with 336 completing successfully and exfiltrating 26 secrets from 13 repositories.

GitHub's approval controls stopped most of the bad workflows, but attackers recycled 92 older ones left behind from earlier attacks, including infrastructure active since September 2025. GitGuardian also found that by October 5, only 16% of the affected repositories, 124 out of 772, had been cleaned up.

Analysis

Why This Matters

The attack undermines trust in the open source supply chain: a single set of stolen developer credentials can be used to spread malicious code through thousands of repos with no vulnerability in the platform itself.
AI provider API keys were specifically targeted, meaning organisations using AI services through CI/CD pipelines face a direct financial and security risk from credential exfiltration.
The low cleanup rate, only 16% of affected repositories, suggests many organisations may still have malicious workflows or leaked secrets in place and not know it.

Background

GitHub Actions is a widely used automation service that lets developers run workflows triggered by repository events. These workflows often reference secrets such as API keys and cloud credentials, making them an attractive target for attackers trying to steal access to production systems. A previous high-profile incident, the tj-actions/changed-files compromise, poisoned a shared Action relied on by thousands of projects. GhostAction is a different technique: rather than exploiting a vulnerability in a third-party Action, attackers used legitimate but stolen credentials to edit workflows directly, blending malicious jobs into normal development activity.

Key Perspectives

GitGuardian and StepSecurity: Security researchers are the primary source of information here. They are tracking the campaign across multiple phases, have identified the infrastructure used for exfiltration, and are calling on affected organisations to rotate credentials and audit their workflow history.

GitHub: GitHub is not directly quoted in the reporting, but its approval controls are described as having stopped most of the bad workflows, suggesting the platform's safeguards provided partial mitigation. The company has not been reported as confirming the scope of the compromise.

Critics and Skeptics: The biggest concern is the unknown: the total number of stolen credentials and how the initial 1,900 accounts were compromised. StepSecurity suspects personal access tokens from credential dumps, but that remains unconfirmed. The slow cleanup of affected repositories also suggests that disclosure and remediation efforts may not be reaching all victims.

What to Watch

Whether GitHub publishes its own accounting of affected accounts and repositories, and whether it enforces rotation of personal access tokens or adds further approval controls for workflow changes.
Whether security researchers identify the original source of the credential dumps, which would determine if this is a repeatable technique or a one-off compromise.
The next phase of the campaign: attackers have recycled older malicious workflows before, and organisations that have not cleaned up their Git history remain exposed to further exfiltration.

Sources

Hackers hijacked 1,900 GitHub accounts. Then they went after 30,000 repos. — The New Stack