Attackers compromised roughly 1,900 GitHub accounts, then leveraged them to inject malicious workflows designed to steal credentials from more than 30,000 repositories, according to a report by GitGuardian. The campaign, dubbed GhostAction, focused on extracting CI/CD secrets, cloud access keys, and API credentials for AI services. The attack escalated sharply on October 8 and 9, when perpetrators reached repositories tied to approximately 3,000 users and organizations and attempted to extract 3,174 secrets.

The attackers inserted disguised workflows that mimicked routine security tasks, using file names such as security-audit.yml or github_actions_security.yml to avoid detection. Once inside repositories, the malicious code referenced secrets already employed by legitimate builds, allowing the fraudulent jobs to harvest credentials when executed and transmit them to a server controlled by the attackers. The October version went further by deploying actions/checkout@v4 with fetch-depth: 0, scanning both active code and complete Git history for AWS keys, GitHub and GitLab personal access tokens, Google and Firebase keys, and API tokens from Anthropic, OpenAI, and OpenRouter. Later iterations captured adjacent lines to match AWS key IDs with their corresponding secret access keys, and the stolen credentials were sent via HTTP to 193.32.204.199, including keys removed from current code but still present in repository history.

During earlier phases in August and September, GitGuardian identified malicious workflows in 772 public repositories across 373 users and organizations. Of 3,669 workflow runs recorded across 605 repositories, only 499 actually executed, with 336 completing successfully and exfiltrating 26 secrets from 13 repositories. GitHub's approval controls blocked most fraudulent workflows, yet attackers simply reused 92 older workflows abandoned from prior attacks, including infrastructure active since September 2025. The report notes that "this payload was deployed in multiple phases," describing an initial push to about 160 previously targeted victims and, 20 minutes later, a much larger deployment into 28,000 new repositories across October 8 and 9. By October 5, only 16% of affected repositories—124 out of 772—had been cleaned up.

The source of the initial breach remains uncertain, but StepSecurity's October 9 analysis suggests personal access tokens extracted from credential dumps as the probable origin, though the first compromise hasn't been verified. Unlike the tj-actions/changed-files incident, which poisoned a shared Action used by thousands of repositories through a vulnerability, GhostAction took a different path: stolen developer credentials allowed direct workflow modification without exploiting any flaw in GitHub Actions itself. With repository access secured, attackers could add malicious workflows that blended seamlessly with standard security operations, granting them the opportunity to collect credentials during normal build processes and route them to external servers. The report emphasizes that GitHub audit records and personal access token activity can help pinpoint which accounts altered .github/workflows/, while Actions run histories reveal which jobs ran and what secrets they could access.

Any compromised account retaining write access needs credential revocation, even after malicious workflows have been deleted. Cloud keys, deployment credentials, registry tokens, and AI provider API keys potentially exposed during the operation also require revocation or rotation, including those removed from the codebase months earlier but still valid when attackers scanned Git history. 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 didn't determine how many distinct credentials reached the attackers. Organizations now face a dual remediation challenge: identifying which accounts were breached and rotating all secrets that might have been accessed, even those buried in version control history. The persistence of unpatched repositories—84% still vulnerable weeks after the initial wave—suggests cleanup efforts are lagging far behind the scope of compromise. For enterprises relying on GitHub Actions for continuous integration, the incident highlights how credential hygiene and repository access controls function as the primary defense layer, since the attack exploited legitimate platform features rather than software vulnerabilities.