AIByer • Independent Technology Newsroom
AIByer
Cybersecurity/12 October 2026

GhostAction GitHub Actions Campaign Hit About 345 Repositories in October Burst

The credential-stealing workflows targeted repository secrets and cloud credentials; broader claims of tens of thousands of affected repositories remain unverified.

AIByer Newsroom

Reporting • Verification • Editorial review

4 min read
Cybersecurity

AIByer Visual Desk

AIByer editorial illustration

Researchers documented a GhostAction-related campaign that injected malicious GitHub Actions workflows into approximately 345–346 repositories on October 8, 2026. The workflows searched repository files and Git history for credentials and sent collected data to an external IP address. Socket separately attributed activity affecting tens of thousands of repositories and more than 500 GitHub accounts to the broader campaign, but those figures are not independently established in the available evidence.

A GhostAction-related campaign used GitHub maintainer accounts to inject credential-stealing workflows into hundreds of repositories during an October 8, 2026 burst, according to security researchers.

The independently documented activity affected approximately 345–346 repositories. StepSecurity counted 345 repositories, while Socket reported 346, making the exact total unsettled. The affected projects included the popular Pyxel project, `kitao/pyxel`, and Uber-owned `uber/athenadriver`.

Socket has also attributed a broader scope to the campaign, saying its activity affected tens of thousands of repositories and involved more than 500 GitHub accounts. Those figures have not been independently quantified in the available primary evidence and should not be treated as the confirmed scope of the October burst.

How the malicious workflows operated

The injected GitHub Actions workflows could run when code was pushed to a repository or when manually dispatched. They used `fetch-depth: 0`, which made the full repository history available to the workflow, rather than only the latest revision.

The workflows searched repository files and Git history for credentials and other sensitive values. Their targets included GitHub Actions secrets and credentials associated with AWS, Anthropic, OpenAI, OpenRouter, GitHub, GitLab, Google and Firebase, Slack, and SendGrid.

The collected information was sent over HTTP to `193.32.204.199`. Researchers confirmed successful exfiltration from `uber/athenadriver`, establishing that credential theft occurred in at least one observed run. That finding does not establish that every targeted credential was successfully extracted or later misused.

The available evidence indicates that the workflows were pushed using maintainer accounts. Researchers inferred the use of stolen credentials, but did not establish how those credentials were obtained. For that reason, describing the accounts simply as “compromised” would overstate what has been independently demonstrated.

October activity followed an earlier wave

The October burst was not the only GhostAction-related activity documented in the supplied reporting. GitGuardian recorded an earlier wave running from August 31 through September 30, 2026. That wave affected 772 repositories and targeted 2,577 secrets.

Those figures describe the earlier period and should not be combined with the approximately 345–346 repositories documented on October 8. The evidence does not establish that the two counts represent one continuous, fully measured operation, nor does it provide a single independently verified total for the broader campaign.

GitGuardian also reported cryptominer activity in its analysis, but cautioned that the evidence could indicate separate actors. The mining activity should therefore not automatically be attributed to the same operator behind the credential-stealing workflows.

GitHub’s approval protection

GitHub introduced automatic approval holds for potentially malicious workflows on July 28, 2026. The protection applies automatically to certain workflows in public repositories on github.com.

That measure is not a universal safeguard for GitHub Actions. Its scope does not mean every workflow, repository, or deployment is automatically protected from malicious changes. The October activity therefore remains relevant even after the feature was introduced, particularly for repositories and workflows outside the protection’s stated coverage or where malicious changes could be approved or otherwise executed.

What repository owners should address

The documented activity makes the workflow files themselves an important part of incident response. Organizations investigating exposure should review repositories for unauthorized GitHub Actions workflows, including workflows triggered by pushes or manual dispatches, and examine changes across relevant branches, tags, and forks according to the repository’s operating model.

Where an account was used to inject a workflow, remediation should also address the credential and access paths that enabled the change. The supplied guidance specifically calls for revoking the relevant GitHub credential, sessions, tokens, OAuth grants, and SSH keys. Any exposed service credentials should be handled according to the affected provider’s response process.

Because the payload searched both current files and Git history, reviewing only the latest version of a repository may not be sufficient to understand what the workflow could access. The confirmed exfiltration from `uber/athenadriver` also shows that the activity was not limited to attempted modification: at least one run transmitted collected data externally.

What remains unconfirmed

The strongest independently supported conclusion is that malicious workflows were injected into roughly 345–346 repositories during the October 8 burst and that the workflows were designed to collect credentials. The exact count differs between StepSecurity and Socket, and no evidence supplied here resolves that discrepancy.

The broader claim that the campaign affected tens of thousands of repositories comes from Socket’s reporting, but no reproducible repository-level accounting or GitHub confirmation was provided. Similarly, Socket’s count of more than 500 GitHub accounts remains a reported figure rather than an independently verified total.

The evidence also does not confirm that all activity came from one GhostAction operator or group. Nor does it establish misuse of every credential targeted or exfiltrated. Those distinctions matter when assessing the incident’s scope and deciding which systems require follow-up.

For now, the verified picture is narrower but still significant: a coordinated burst used trusted maintainer access to place credential-stealing automation in hundreds of repositories, with confirmed exfiltration in at least one case. The larger campaign estimates remain claims requiring additional independent accounting.

Analysis

Why it matters

The campaign abused trusted repository access and GitHub Actions automation to search both source trees and Git history for credentials across major cloud, AI, developer, messaging, and email services. Confirmed exfiltration from one repository shows that the activity went beyond attempted workflow injection, while the unresolved scope makes precise exposure assessment important.

Practical guidance

What to know

01

Review repositories for unauthorized GitHub Actions workflows and changes across relevant branches, tags, and forks.

02

Revoke the GitHub credential, sessions, tokens, OAuth grants, and SSH keys that enabled unauthorized workflow injection.

03

Assess and rotate exposed service credentials through the affected providers’ response processes.

04

Review repository files and Git history because the workflows searched both locations.

05

Consider GitHub’s automatic approval holds in context: the protection applies to certain workflows in public repositories on github.com and is not universal.

Transparency

Sources