Hackers Hijack 790 GitHub Repositories to Steal Cloud Credentials and AI API Keys

A supply-chain campaign known as GhostAction has reportedly affected 790 GitHub repositories, exposing potentially sensitive cloud credentials, software-publishing tokens, and artificial intelligence (AI) API keys to theft.

Researchers at OpenSourceMalware identified the latest stage of the campaign while investigating a malicious PyPI package named claudecord and assisting its maintainer. Their investigation uncovered malicious GitHub Actions workflows designed to search repositories and Git history for credential-like strings before sending collected information to attacker-controlled infrastructure.

The figure of 790 represents publicly recoverable, validated repositories identified by OpenSourceMalware through October 9, 2026. It does not mean every repository leaked credentials or experienced confirmed unauthorized use.

The campaign demonstrates how compromised developer accounts and trusted automation workflows can create risks extending beyond a single repository, potentially affecting cloud environments, package registries, and AI-powered applications.

GhostAction Campaign Targets 790 GitHub Repositories

GhostAction abuses access to GitHub repositories to introduce malicious GitHub Actions workflows. These workflows can execute automatically when code is pushed or when a workflow is manually started, depending on their configuration.

Once a compromised account can modify a repository, an attacker may be able to introduce automation that runs within the project’s continuous integration and continuous delivery (CI/CD) environment.

The security implications depend on the permissions available to the workflow, the secrets exposed to its execution environment, and the network destinations it can reach.

According to OpenSourceMalware, the newer GhostAction workflow goes beyond reading selected GitHub Actions secrets. It also searches repository files and accessible Git history for strings resembling credentials associated with services such as AWS, GitHub, GitLab, Google, Slack, SendGrid, OpenAI, Anthropic, and OpenRouter.

These findings make the campaign particularly relevant to development teams that rely on automated builds, cloud deployments, and AI services.

How the Malicious GitHub Actions Workflow Steals Credentials

The reported workflow uses several collection techniques to identify potentially sensitive information.

1. Scanning Repository Files

The workflow searches files for strings matching credential patterns. These may include cloud access keys, API tokens, and other authentication material accidentally committed to source code.

Developers sometimes remove exposed credentials from the latest version of a file without eliminating them from the repository’s history. As a result, a secret that no longer appears in the current source tree may still require remediation.

2. Searching Git History

The campaign reportedly uses the Git configuration fetch-depth: 0 to retrieve the repository’s complete accessible history rather than only a limited recent snapshot.

The workflow then searches historical changes for credential-like strings. In some cases, it collects surrounding lines associated with AWS access key identifiers, potentially revealing additional context about related credentials or services.

This technique highlights why deleting a secret from a current file does not guarantee that the secret has been removed from all accessible repository history.

3. Collecting Data From CI/CD Runners

After collecting potential secrets, the malicious workflow reportedly transmits the information to attacker-controlled infrastructure over plain HTTP.

Because this traffic originates from a CI runner, it may be overlooked if defenders monitor only conventional user workstations or focus exclusively on suspicious inbound connections.

Organizations should therefore examine workflow modifications alongside build logs, runner activity, and unexpected outbound network traffic.

Campaign Activity Increased Across Multiple Repositories

The supplied report describes several investigations that measured GhostAction activity across different periods.

GitGuardian reported 772 affected repositories between August 31 and September 30, 2026. OpenSourceMalware subsequently identified 790 publicly recoverable, validated repositories through October 9.

Separately, Socket and StepSecurity reported activity across 346 repositories associated with two compromised accounts during an October 8 burst. The reported activity included repositories owned by kitao and henrywoo, as well as uber/athenadriver.

These figures cover different time periods and evidence sets. They should not be added together to produce a combined campaign total.

The reported activity reached active projects, forks, and repositories that had remained dormant for years. This suggests that compromised accounts could be used to modify a wide range of repositories accessible to them.

As of October 9, the report had not identified malicious PyPI or crates.io releases linked to the latest burst. That finding does not rule out credential exposure or other forms of misuse.

Why Removing a Malicious Workflow Is Not Enough

Deleting a malicious workflow can stop that particular workflow from running again, but it does not automatically undo the consequences of earlier executions.

If credentials were collected during a successful run, an attacker may retain copies even after the workflow disappears from the repository.

A stolen token may remain valid until it is revoked or expires. Similarly, cloud credentials, package-publishing tokens, and AI service keys may continue to work independently of the GitHub workflow that exposed them.

Organizations responding to a suspected GhostAction compromise should:

1. Preserve relevant workflow files, commit history, execution logs, and audit records.
2. Revoke compromised GitHub tokens and investigate the account that introduced the workflow.
3. Rotate every secret that the affected workflow could access, including cloud, publishing, and AI service credentials.
4. Review cloud audit logs, package publication history, deployment activity, and AI service usage for suspicious behavior.
5. Inspect related repositories and forks that the compromised account could modify.
6. Remove malicious workflow changes and restore trusted repository configurations after preserving evidence.

Teams should prioritize containment and credential rotation based on the scope of access available to the compromised workflow.

Indicators of Compromise (IoCs)

The following indicators are reproduced from the supplied report. They should be validated against trusted threat-intelligence sources before being used for blocking or attribution.

IoC handling note: The IP addresses and domains are defanged to reduce accidental access. The supplied report identifies my-github[.]com as suspicious but does not prove who registered it. It also lists my-gitlab[.]com as a watch item rather than confirmed campaign infrastructure. Preserve these distinctions when creating detections.

How to Secure GitHub Actions Against Credential Theft

Development teams can reduce exposure by limiting what automated workflows can access and by treating workflow changes as security-sensitive code.

Apply Least-Privilege Permissions

Grant workflows only the repository permissions they require. Review the default GITHUB_TOKEN permissions and avoid granting broad write access to jobs that only need to read source files or run tests.

Protect Secrets and Credentials

Avoid storing long-lived credentials directly in source code or Git history. Use appropriately scoped secrets, short-lived credentials, and trusted identity federation where supported.

If a workflow may have accessed a secret, rotate that secret rather than assuming that deleting the workflow has resolved the exposure.

Review Workflow Changes

Require appropriate review for modifications to files under .github/workflows/. Pay particular attention to unexpected network requests, credential-search logic, unfamiliar actions, and changes to workflow triggers or permissions.

Where appropriate, require approval before sensitive workflows run against protected environments.

Monitor Outbound Network Activity

CI runners should not automatically have unrestricted access to every external destination. Use network controls and monitoring appropriate to the build environment, and investigate unexplained outbound HTTP traffic from workflow executions.

Audit Repository and Account Activity

Review audit logs for unexpected workflow creation, repository modifications, permission changes, token use, and unusual package publications. Investigate whether the compromised account had access to other projects or organizational resources.

GitHub’s official Secure Use reference for GitHub Actions provides further guidance on securing workflows and managing permissions.

Conclusion

The GhostAction campaign illustrates how compromised developer accounts and malicious CI/CD workflows can turn trusted software automation into a route for credential exposure.

OpenSourceMalware’s reported total of 790 publicly recoverable, validated repositories highlights the campaign’s reach, but it should not be interpreted as proof that every repository suffered a confirmed credential theft incident.

Organizations should investigate workflow changes, examine historical commits, rotate potentially exposed credentials, and review cloud and package-registry activity. Restricting workflow permissions and monitoring runner behavior can help reduce the risk of similar attacks.

As development pipelines increasingly connect source code with cloud infrastructure and AI services, securing automation is an essential part of protecting the software supply chain.

CyberExy — Secure Tomorrow.

Sources

• OpenSourceMalware — GhostAction Attack Escalates
• GitHub — Secure Use Reference for GitHub Actions
• Cyber Security News — GhostAction Supply Chain Campaign
• Cyber Security News — GitHub Actions Workflows Used to Steal PyPI Tokens
• Cyber Security News — AI Token Jacking