GhostAction hit 30,000 GitHub repositories through 1,900 hijacked accounts

A credential-stealing campaign on GitHub Actions ran mostly on 8 and 9 October, and the workflow that stole the secrets was signed in as the repository owner.

GitGuardian wrote that a campaign it calls GhostAction had hijacked around 1,900 GitHub accounts and used them to plant malicious Actions workflows in more than 30,000 repositories. The New Stack, writing up GitGuardian's work, said the biggest push ran on 8 and 9 October, when the attackers reached repositories belonging to about 3,000 users and organisations and targeted 3,174 secrets.

How a worker added itself to the build

GitGuardian wrote that GhostAction did not exploit a flaw in GitHub Actions. The attackers used stolen developer credentials to edit workflows in repositories they already had write access to. StepSecurity's analysis points to personal access tokens from credential dumps as the likely source of those credentials, with the initial step not confirmed.

The planted workflows carried names that look like safety work, such as security-audit.yml or github_actions_security.yml, and they referenced the same secrets the real build uses. When the job ran, those secrets were in its environment, and the step sent them to a server the attackers controlled at IP address 193.32.204.199 over plain HTTP.

The October variant scanned Git history

The newer workflows went past the secrets the build referenced. The job checked out the repository with actions/checkout@v4 and fetch-depth: 0, which pulls the whole Git history, and then scanned both the working tree and that history for AWS keys, GitHub and GitLab personal access tokens, Google and Firebase keys, and API tokens from Anthropic, OpenAI and OpenRouter. Later versions kept lines around each match, so an AWS access key ID would travel out of the repository paired with its secret.

GitGuardian wrote that the payload "was deployed in multiple phases", starting with about 160 earlier victims and then, 20 minutes later, 28,000 new repositories across 8 and 9 October. The total number of credentials that reached the attackers is not known. GitGuardian confirmed some exfiltration during the October push and counted 3,174 secrets as the targets, but did not say how many distinct keys were taken.

Across the earlier August and September campaign, GitGuardian counted malicious workflows in 772 public repositories across 373 users and organisations, 3,669 workflow runs in 605 repositories, and 499 runs that executed. Of those, 336 completed and exfiltrated 26 secrets from 13 repositories. By 5 October, only 124 of those 772 earlier repositories, 16 percent, had been cleaned up.

What to do today

GitHub blocked the malicious workflows, which is why most of them did not run. GitHub's own approval controls stopped a large share of the attempts. The exposure that remains is any secret that was in reach of a workflow run that did execute, or in reach of a job that scanned the full Git history during the window. GitGuardian pointed to audit records of changes to .github/workflows/ and to Actions run histories as the two places to look.

Any compromised account that still has write access needs its credentials revoked, GitGuardian wrote, whether or not the malicious workflow has already been removed from the repository. Cloud keys, deployment credentials, registry tokens and AI provider API keys that may have been exposed need to be rotated, including keys that were deleted from the current code months ago but still appear in Git history.

Source

• GitGuardian, "GhostAction Returns: 772 Repos Hit, 30k More in Oct"
• The New Stack, "Hackers hijacked 1,900 GitHub accounts. Then they went after 30,000 repos.", Amanda Caswell
• StepSecurity, "GhostAction Returns"