GhostAction Supply Chain Campaign Steals CI/CD Credentials via GitHub Actions

Key Takeaways

• A renewed GhostAction supply chain campaign has compromised 772 public GitHub repositories, stealing credentials from CI/CD environments.
• The attackers utilized fake GitHub Actions workflow files to exfiltrate 2,577 secrets from 373 GitHub users and organizations.
• The campaign, active from August 31 to September 30, 2026, targeted a wide range of sensitive data, including cloud keys, SSH credentials, and container registry logins.
• The threat actors leveraged stolen GitHub account access to inject malicious workflows, often disguised as security updates.
• Many compromised repositories remain uncleaned, and organizations are urged to revoke affected credentials and rotate secrets.

GhostAction Supply Chain Campaign Resurfaces, Targets GitHub CI/CD Credentials

A sophisticated supply chain attack, dubbed GhostAction, has re-emerged, compromising 772 public GitHub repositories. The campaign, active between August 31 and September 30, 2026, successfully pilfered 2,577 secrets from 373 distinct GitHub user accounts and organizations. These stolen credentials encompassed a wide array of sensitive information, including cloud keys, SSH credentials, container registry logins, database passwords, and GitHub tokens, all extracted from continuous integration/continuous deployment (CI/CD) environments.

According to an investigation by GitGuardian, the attackers gained unauthorized access to GitHub accounts and then injected malicious workflow files under the legitimate user’s identity. This tactic allowed the attackers to camouflage their activities, making the malicious additions appear as routine automation updates and thus easily overlooked during standard code reviews.

Modus Operandi: Malicious Workflows and Targeted Exfiltration

The primary method involved adding a workflow file, typically named github_actions_security.yml, accompanied by the commit message “Add Github Actions Security workflow.” This workflow was designed to activate upon a standard repository push event. Once triggered, it would meticulously identify and extract specific GitHub Actions secrets, subsequently transmitting them to attacker-controlled infrastructure via a curl POST request. This technique bears a striking resemblance to earlier credential theft campaigns that exploited seemingly innocuous CI update workflows to siphon off tokens and cloud credentials.

GitGuardian analysts uncovered this latest wave of GhostAction activity after independent researchers at Cynative first identified suspicious commits and alerted the company. GitGuardian first disclosed GhostAction in September 2025, when the campaign affected 817 public repositories and compromised at least 3,325 secrets. The current findings indicate that GhostAction was not a transient threat; malicious workflows from previous iterations persisted in some repositories and were subsequently updated with new data exfiltration endpoints, demonstrating the campaign’s enduring nature.

Rather than indiscriminately collecting all available variables, the GhostAction workflow intelligently scans a repository’s existing workflow and configuration history for secret references formatted as ${{ secrets.NAME }}. It then inserts these precise secret names into the malicious workflow. This targeted approach ensures the collection of credentials that are highly valuable for deployment, publishing, cloud management, or source-code access.

The most recent payload transmits data over plain HTTP to the IP address 193.32.204.199, replacing older GhostAction infrastructure. A smaller variant, observed in seven repositories, utilized security-check.yml with the workflow name “Security Check” and the commit message “Add security check workflow.” This variant directed data to an API endpoint containing a unique injection identifier, suggesting the operators might be tracking stolen credentials on a per-repository or per-workflow instance basis. The use of hidden workflow persistence also aligns with the tactics seen in the Shai-Hulud npm supply chain attack, which injected GitHub Actions files to maintain secret collection post-initial compromise.

GitGuardian documented three significant spikes in this new wave: 143 repositories on August 31; approximately 400 repositories between September 2 and 5, with 294 on September 5 alone; and 103 repositories on September 15. Of 3,669 workflow runs examined across 605 repositories, GitHub held the majority for approval. Nevertheless, 499 runs executed in 32 repositories, and 336 runs completed successfully, leading to the theft of 26 secrets from 13 repositories. The most frequently targeted credentials were SSH private keys and deployment-server credentials, accounting for 446 secret references. Azure credentials were targeted 218 times, while Docker Hub and GitHub Container Registry credentials appeared 142 times. The workflows also sought database passwords, AWS access keys, FTP credentials, Google Cloud and Firebase credentials, GitHub tokens, and API tokens for services like Cloudflare, npm, PyPI, Slack, Telegram, Discord, and various AI platforms. This broad targeting underscores the increasing risk associated with the abuse of trusted developer tooling, where build pipelines and developer systems serve as conduits to cloud and source-code access.

GhostAction Campaign Never Truly Ceased

A compelling indicator of the campaign’s persistence is that in 92 instances, the attackers did not create new workflows but instead updated existing compromised files using the commit message “Update Github Actions Security workflow.” These files had survived from earlier campaign periods and were modified to utilize the new collection server. Researchers connected this workflow pattern to older endpoints, including bold-dhawan.45-139-104-115.plesk.page, carte-avantage.com, 170.39.218.2, and *.oast.fun Interactsh domains.

As of October 5, only 124 of the 772 affected repositories (16%) had been effectively cleaned in their public commit history. This low cleanup rate is critical because a malicious workflow can re-execute every time a developer pushes a legitimate commit. Therefore, organizations must consider workflow removal as only one component of their incident response. It is imperative to identify how the attacker gained repository write access, revoke the compromised GitHub credential, thoroughly review workflow runs and audit logs, and rotate every secret that might have been accessible to the runner.

GitHub recommends that teams restrict each workflow and GITHUB_TOKEN to the absolute minimum necessary permissions, meticulously audit workflow source code and third-party actions, and pin actions to a full commit SHA for immutable referencing. Organizations should also implement environment approval controls for sensitive deployment secrets and rigorously review any newly added or modified files within the .github/workflows/ directory. GitHub’s secure-use guidance emphasizes that even if a secret was masked in logs, an exposed secret must be rotated.

GitGuardian also discovered a cryptominer in the kuafuai/DevOpsGPT repository, which subsequently fell victim to GhostAction. However, researchers did not attribute both incidents to the same operator. The cryptominer employed a forged author email, a tailored payload, an XMRig binary disguised as /usr/local/bin/pyworker, and exhibited a distinct operational style, contrasting with GhostAction’s broad, automated GitHub API workflow injection. This overlap, nonetheless, highlights a critical issue: stolen GitHub credentials can be exploited by multiple, unrelated threat groups. A compromised maintainer account can serve as a gateway for collecting CI/CD secrets, injecting malicious code, publishing altered packages, or executing cryptomining workloads. Recent software supply chain threat activity underscores that a single developer identity can provide a pathway into build systems, cloud accounts, package registries, and downstream customer environments.

For cybersecurity defenders, the paramount lesson is robust identity control. Teams must not only eliminate suspicious workflow files and rotate cloud keys but also revoke exposed GitHub personal access tokens, enforce phishing-resistant multi-factor authentication, mandate review for workflow changes, apply least-privilege permissions, and monitor outbound network traffic from CI runners. In GhostAction incidents, leaving the original stolen GitHub credential active could enable the same operator—or another actor possessing that credential—to reinfiltrate.

What You Should Do

• Revoke Compromised Credentials: Immediately revoke any GitHub personal access tokens or other credentials suspected of being compromised.
• Audit and Rotate Secrets: Conduct a comprehensive audit of all secrets accessible to CI/CD runners and rotate any that may have been exposed.
• Review Workflow Changes: Implement mandatory review processes for all changes to workflow files within the .github/workflows/ directory.
• Enforce Least Privilege: Configure GitHub Actions workflows and GITHUB_TOKENs with the minimum necessary permissions.
• Implement MFA: Enforce phishing-resistant multi-factor authentication for all GitHub accounts.
• Monitor Outbound Traffic: Actively monitor outbound network traffic from CI runners for unusual activity or connections to suspicious IP addresses.
• Clean Repositories: Thoroughly remove any malicious workflow files and ensure commit history is cleaned where appropriate.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.