A sophisticated and coordinated malicious operation known as the GhostAction campaign has compromised approximately 1,900 GitHub accounts, utilizing unauthorized access to inject credential-stealing workflows into more than 30,000 software repositories. Monitored closely by cybersecurity firms including GitGuardian and StepSecurity, the campaign represents a severe escalation in supply chain threats targeting continuous integration and continuous deployment (CI/CD) environments. By weaponizing legitimate automation features, the attackers systematically targeted critical cloud access keys, AI provider application programming interface (API) tokens, and sensitive infrastructure secrets across a vast array of open-source and enterprise codebases.
The scale of the operation reached its peak during a rapid, multi-phase deployment on October 8 and 9, during which the attackers successfully breached repositories belonging to roughly 3,000 distinct users and organizations. Security telemetry indicates that the threat actors attempted to extract 3,174 specific secrets during this intense window. This wave of attacks follows an earlier, smaller reconnaissance and testing phase observed in August and September, signaling a calculated progression from localized probing to widespread automated exploitation.
Understanding the Attack Vector and Credential Compromise
Unlike previous supply chain incidents that relied on exploiting third-party vulnerabilities within shared marketplace actions—such as the notable tj-actions/changed-files compromise—GhostAction adopted a more direct and invasive route. The threat actors utilized stolen developer credentials, likely obtained through historical credential dumps and compromised personal access tokens (PATs), to log directly into victim accounts. Once inside, the attackers manually or programmatically altered existing repository workflows without needing to exploit any zero-day flaws within the GitHub Actions platform itself.
With write access established, the attackers introduced malicious YAML workflow files disguised as routine administrative or security tasks. Employing benign-sounding file names such as security-audit.yml or github_actions_security.yml, the injected jobs were designed to blend seamlessly into standard developer operations. These rogue workflows were strategically configured to reference the same environment secrets utilized by legitimate builds. When the automated pipelines executed, the malicious scripts intercepted these sensitive tokens, bundling them and transmitting the stolen data over unencrypted HTTP requests to an external attacker-controlled server identified by the IP address 193.32.204.199.
Chronology and Phased Deployment of the GhostAction Campaign
The evolution of the GhostAction campaign reveals a disciplined operational timeline characterized by careful preparation, phased execution, and rapid adaptation to platform defenses. Initial indicators of the campaign emerged in August and September, when cybersecurity researchers identified malicious workflows scattered across 772 public repositories belonging to 373 distinct users and organizations. During this preliminary phase, GitGuardian recorded 3,669 workflow runs across 605 repositories. However, due to restrictive execution policies and manual approval gates, only 499 of these jobs executed, with 336 completing successfully and managing to exfiltrate 26 unique secrets from 13 repositories.
Recognizing that strict platform approval controls were blunting the effectiveness of newly introduced malicious scripts, the threat actors altered their tactics for the October campaign. Rather than relying solely on new injections, the attackers recycled 92 older, pre-existing workflows left behind from their earlier September operations—infrastructure that had remained dormant yet valid within target repositories.
The primary escalation occurred on October 8 and 9 in distinct, calculated waves. According to GitGuardian’s incident breakdown, the attackers initiated a localized deployment targeting approximately 160 previously identified victims to test their updated payloads. Barely twenty minutes later, the operation scaled dramatically, pushing the payload into roughly 28,000 new repositories in a synchronized mass deployment. Security analysts noted that by October 5, just prior to this massive push, only 16 percent of the repositories affected by the initial August-September wave—124 out of 772—had been properly cleaned up, leaving a vast pool of vulnerable targets ripe for exploitation.
Deep-History Scanning and Exfiltration Targets
A defining characteristic of the October GhostAction variant was its aggressive expansion of data-harvesting techniques. Moving beyond the immediate secrets referenced within active workflow configurations, the attackers leveraged the standard GitHub checkout action with specific parameters (actions/checkout@v4 with fetch-depth: 0). This command instructs the runner to download the entire working tree alongside the complete, unedited Git history of the repository.
By scanning deep into historical commits, the malicious scripts were able to unearth sensitive credentials that had long been deleted from the active codebase but remained preserved in the repository’s version control logs. The targeted credentials spanned a wide spectrum of modern cloud and enterprise infrastructure, including Amazon Web Services (AWS) key IDs and secret access keys, GitHub and GitLab PATs, Google Cloud Platform and Firebase credentials, and high-value API tokens from artificial intelligence providers such as Anthropic, OpenAI, and OpenRouter. Later iterations of the malware even captured surrounding lines of code to intelligently pair AWS key IDs with their corresponding secret access keys, ensuring the harvested credentials were fully functional upon receipt by the attackers.
Platform Response and Remediation Challenges
In response to the anomalous activity, GitHub deployed automated blocking mechanisms to halt many of the malicious workflows and restrict unauthorized executions. Despite these platform-level interventions, the sheer volume of affected repositories created a massive remediation bottleneck for individual developers and enterprise security teams.
The challenge of complete remediation is compounded by the persistence of developer access. Cybersecurity experts emphasize that simply deleting the malicious YAML files or purging a repository of rogue workflows is insufficient to secure an environment. Because the campaign relied on compromised personal credentials to gain initial entry, any user account that retained active write permissions remained a vector for reinfection. Furthermore, the broad scope of Git-history scanning means that organizations must assume any cloud key, deployment token, or AI service credential exposed at any point in the repository’s history has been compromised and is likely residing on external attacker servers.
Recommendations and Broader Industry Implications
Security researchers and platform administrators have issued comprehensive remediation guidelines for organizations potentially impacted by the GhostAction campaign. The primary defensive steps require a thorough forensic review of GitHub audit records and PAT activity logs to pinpoint which accounts modified files within the .github/workflows/ directory. Additionally, analyzing historical Actions run data can reveal which jobs executed and which secrets they were granted access to during the execution window.
Mandatory remediation steps include:
- Revoking all personal access tokens and OAuth app authorizations associated with compromised accounts, regardless of whether the specific malicious workflow has been removed.
- Completely rotating all AWS, Google Cloud, and third-party infrastructure keys that were exposed or present in Git history at any time.
- Invalidating and reissuing all developer and production API tokens for AI platforms, deployment pipelines, and code repositories.
- Implementing strict branch protection rules and requiring multi-person reviews for any modifications made to CI/CD pipeline configurations.
The GhostAction campaign serves as a stark reminder of the fragile nature of modern software supply chains. As development teams increasingly rely on automated CI/CD pipelines and integrate powerful third-party AI services into their workflows, repositories have transformed into lucrative targets for cybercriminals. The incident underscores the critical necessity for continuous credential hygiene, proactive secret scanning across full version histories, and the enforcement of principle-of-least-privilege access controls across all software development environments.
