GhostAction campaign hijacks GitHub accounts to steal CI/CD and AI secrets

A coordinated cyber campaign known as GhostAction compromised approximately 1,900 GitHub accounts in October 2026. The attackers used these access points to inject malicious GitHub Actions workflows into more than 30,000 repositories, aiming to exfiltrate sensitive credentials including cloud access keys and AI provider API tokens.

What happened

The attack intensified on October 8 and 9, 2026, when the threat actors targeted repositories belonging to roughly 3,000 users and organizations. During this peak period, the malicious workflows attempted to extract 3,174 distinct secrets. GitGuardian, which tracked the campaign, noted that the attackers deployed the payload in multiple phases. An initial push targeted about 160 previously victimized accounts, followed twenty minutes later by a much larger deployment affecting 28,000 new repositories.

Unlike previous supply chain attacks that exploited vulnerabilities in shared actions, such as the tj-actions/changed-files compromise, GhostAction relied on stolen developer credentials. StepSecurity analysis from October 9 suggests the attackers likely used personal access tokens obtained from credential dumps, although the initial source of these credentials remains unconfirmed. With valid write access, the attackers modified repository workflows directly, bypassing the need for any vulnerability in the GitHub Actions platform itself.

The malicious files were disguised with innocuous names like security-audit.yml or github_actions_security.yml. These fake jobs referenced secrets already used by legitimate build processes, allowing them to run without raising immediate suspicion while harvesting credentials in the background. GitHub’s approval controls blocked many of these workflows, but the attackers adapted by recycling 92 older workflows from previous attacks, some of which had been active since September 2025.

How it works

The core mechanism of the attack involved injecting YAML workflow files that executed standard checkout actions with aggressive history fetching. Specifically, the workflows used actions/checkout@v4 with the parameter fetch-depth: 0. This configuration instructs the runner to download the entire Git history rather than just the latest commit. By accessing the full history, the malicious scripts could scan not only the current working tree but also past commits for hardcoded secrets.

The scanners looked for a wide range of credentials, including AWS keys, GitHub and GitLab personal access tokens, Google and Firebase keys, and API tokens from AI providers such as Anthropic, OpenAI, and OpenRouter. Later iterations of the malware improved their extraction logic by capturing surrounding lines of code, enabling them to pair AWS key IDs with their corresponding secret access keys even if they were separated in the file structure.

Once harvested, the credentials were sent over HTTP to an attacker-controlled server at IP address 193.32.204.199. This method allowed the attackers to retrieve keys that had been removed from the current codebase months or years ago but remained accessible in the Git history. The exfiltration process was silent, leveraging the legitimate execution environment of GitHub Actions to blend in with normal CI/CD traffic.

Key details

• Approximately 1,900 GitHub accounts were compromised to facilitate the attack.
• Malicious workflows were injected into more than 30,000 repositories across 3,000 users and organizations.
• The attackers targeted 3,174 secrets, including cloud keys and AI provider API tokens.
• Workflows used fetch-depth: 0 to scan full Git history for previously deleted credentials.
• Exfiltrated data was sent via HTTP to the IP address 193.32.204.199.
• Only 16% of affected repositories from earlier phases had been cleaned up by October 5.

Why it matters

This incident highlights a critical blind spot in modern development security: the persistence of secrets in Git history. Many teams assume that removing a hardcoded key from the current branch eliminates the risk. However, because Git is immutable by design, those secrets remain in the history unless explicitly purged. The GhostAction campaign demonstrates that attackers are actively exploiting this gap, using standard CI/CD tools to dig up old credentials that developers may have forgotten.

For engineering leaders and DevOps teams, the reliance on GitHub’s native approval controls is insufficient. While GitHub blocked many malicious runs, the attackers’ ability to recycle old workflows and use valid credentials meant that some exfiltration still occurred. The fact that only 16% of previously affected repositories had been cleaned up months after the initial detection suggests a significant lag in incident response and remediation efforts across the ecosystem.

Furthermore, the targeting of AI provider keys signals a shift in attacker priorities. As companies integrate more AI services into their products, API tokens for providers like OpenAI and Anthropic have become high-value targets. Compromising these keys can lead not only to financial loss through unauthorized usage but also to potential data leakage if the keys grant access to proprietary models or customer data processed by these services.

What you can do

• Audit GitHub audit logs and personal access token activity to identify any accounts that modified .github/workflows/ recently.
• Review GitHub Actions run histories to detect jobs that executed unexpectedly or accessed secrets they did not need.
• Revoke credentials for any compromised account immediately, even if the malicious workflow has already been deleted.
• Rotate all cloud keys, deployment credentials, registry tokens, and AI provider API keys that may have been exposed.
• Scan your full Git history for hardcoded secrets, not just the current head, using tools designed for deep history inspection.
• Implement strict approval requirements for workflow changes and limit the scope of personal access tokens used in CI/CD.