GhostAction Campaign Expands to Steal Cloud Credentials and AI API Keys From GitHub Repositories

GhostAction Expands Its Reach With a New GitHub Credential Theft Technique

A new wave of the GhostAction supply chain campaign is targeting GitHub repositories with malicious automation designed to steal CI/CD secrets, cloud credentials and AI service API keys.

In an investigation published on 9 October 2026, Socket's Research Team detailed how attackers used compromised maintainer accounts to introduce a malicious GitHub Actions workflow disguised as a security audit. The workflow collects configured GitHub Actions secrets and searches repository files and Git history for credentials before transmitting the results to an external server.

Socket initially identified the workflow in 346 repositories associated with two compromised maintainer accounts and an organisation-owned repository. A subsequent update on the same day reported that more than 500 GitHub accounts had committed the malicious workflow to tens of thousands of repositories since 7 October 2026.

The updated findings indicate a wider campaign than the initial repository-level investigation suggested. The two accounts examined in detail remain important examples of how a compromised contributor can introduce malicious automation into projects beyond their personal repositories.

What Is GhostAction?

GhostAction is a supply chain attack campaign that abuses access to software development repositories and automation workflows to collect credentials.

GitGuardian documented earlier activity in September 2025 and reported another wave in 2026. The latest variant retains the earlier technique of extracting GitHub Actions secrets but adds a broader search for credentials stored in repository files and historical commits.

This change matters because developers may remove a sensitive key from the current version of a file while leaving the original value in Git history. A repository's current state therefore does not necessarily reveal every credential that has been exposed.

The campaign also demonstrates how a compromised developer account can become a route into multiple projects. When maintainers have write access to several repositories, attackers may be able to introduce the same malicious workflow wherever those permissions allow.

How the Attack Works

Socket's investigation describes a process that begins with compromised maintainer credentials and ends with the transmission of collected secrets.

1. Compromising a maintainer account

The attackers first obtain working credentials for a GitHub maintainer account.

Socket did not establish how the accounts were compromised. The original method of obtaining access therefore remains undisclosed.

2. Preparing a malicious workflow

The attackers add a file named security-audit.yml under the .github/workflows/ directory.

The filename and workflow description suggest a routine security check. However, Socket's analysis found that the workflow's actual purpose was credential collection.

The injected file was committed directly to the default branch in the repositories examined, allowing it to become part of the project's automation configuration.

3. Collecting secrets and searching repository content

The workflow uses two collection methods.

The first extracts GitHub Actions secrets referenced by the repository's existing workflows. The malicious payload is prepared with the relevant secret names before the workflow is committed.

The second method searches the checked-out files and Git history for recognised credential patterns. It also captures surrounding context for certain AWS access key identifiers to help locate associated secret values.

4. Transmitting the collected data

The workflow combines the collected information into a request and sends it to a hardcoded external IP address using unencrypted HTTP.

Socket identified 193.32.204[.]199 as the destination associated with the activity. The address is defanged here for safe publication.

The workflow can run following pushes and can also be triggered manually. This means its presence in a repository can create an ongoing exposure risk until defenders remove it and address any compromised credentials.

Why the New Git History Search Matters

The most significant technical change in this GhostAction variant is its ability to search beyond the current working tree.

Socket found that the malicious workflow uses fetch-depth: 0 when checking out the repository. This configuration fetches the full available repository history rather than a shallow checkout. The workflow then examines patch content across branches and tags.

This allows the credential search to reach historical changes that are no longer visible in the latest version of a file.

For example, a developer might accidentally commit an API key, discover the mistake and remove the key in a later commit. Although the current file no longer contains the value, the earlier commit may still retain it.

The same issue can affect configuration files, infrastructure definitions, environment files and CI/CD configuration.

The workflow searches for 13 credential patterns across several categories, according to Socket's analysis. These include AWS access credentials, Anthropic and OpenAI API keys, OpenRouter keys, GitHub and GitLab access tokens, Google-related API keys, Slack tokens and SendGrid API keys.

For AWS credentials, the workflow searches for access key identifiers and collects surrounding lines that may contain the corresponding secret access key or other related information. An access key identifier alone is not sufficient to authenticate, but related secret material in nearby configuration lines can make the exposure more serious.

This is why removing a secret from the latest commit is not the same as invalidating it.

Which Credentials Are at Risk?

The workflow targets credentials that may provide access to development infrastructure, cloud resources, AI services and external platforms.

The exact impact depends on the credential's permissions, whether it remains valid and the systems it can access. The presence of a matching string does not, by itself, prove that every associated service was accessed.

However, where the malicious workflow executed successfully, defenders should treat the credentials it collected as potentially exposed.

Which Repositories Were Affected?

Socket's initial analysis focused on two maintainer accounts, henrywoo and kitao, and repositories to which those accounts could write.

The investigation identified the malicious workflow in 346 repositories: 318 associated with the henrywoo namespace, 27 under kitao, and the organisation-owned uber/athenadriver repository.

The affected set included personal repositories, forks and projects that had not been actively maintained for years. This suggests the attackers were exploiting account permissions across available repositories rather than limiting their activity to currently active projects.

Two examples illustrate the potential impact.

Uber's athenadriver repository

Socket identified the malicious workflow in uber/athenadriver, where the contributor account had write access as the repository's original author.

The case highlights an important security consideration: organisational exposure can extend beyond accounts directly managed by an organisation if external or historical contributors retain write access.

The Pyxel project

Socket also identified the workflow in kitao/pyxel, an open-source game engine distributed through PyPI and crates.io.

The workflow referenced publishing credentials and a GitHub personal access token. If misused, publishing credentials could allow an attacker to distribute unauthorised releases through package channels that users already trust.

Socket reported that it had not observed malicious package versions published to PyPI or crates.io as a result of this activity at the time of publication.

That distinction is important. The investigation established credential collection and successful workflow execution in affected repositories, but it did not report a confirmed malicious package release resulting from this specific wave.

What the Campaign Means for AI and Cloud Security

The expansion of credential collection to AI service keys is particularly relevant to organisations that integrate generative AI into their applications and development workflows.

AI API keys may be stored in environment variables, local configuration files, deployment settings or CI/CD secrets. If exposed, they may allow unauthorised API requests and generate unexpected usage costs. Depending on the service and the application's architecture, compromised credentials may also expose access to associated AI workflows.

Cloud credentials introduce a separate concern. Depending on their permissions, exposed keys may provide access to infrastructure, storage or other cloud resources.

The risk is not limited to production systems. Development and testing environments can contain valuable access tokens, deployment credentials and configuration data. A compromised automation workflow can therefore create exposure even when the affected project is not itself a production service.

The broader lesson is that software supply chain security requires more than dependency scanning. It also requires controls over maintainer accounts, workflow changes, repository permissions, secret storage and credential lifecycle management.

How Organisations Should Respond

Socket's recommendations focus on investigating affected repositories, removing the malicious workflow and treating potentially collected credentials as exposed.

Organisations should prioritise the following actions.

1. Search for suspicious workflow files

Inspect repository workflows for these paths:

• .github/workflows/security-audit.yml

• .github/workflows/github_actions_security.yml

Also search for the reported commit messages, including Add security audit workflow, Update security audit workflow and Add Github Actions Security workflow.

These indicators should be assessed alongside the workflow's contents, commit history and execution logs. A filename alone is not sufficient to establish malicious activity in every possible context.

2. Review workflow execution history

Identify whether the suspicious workflow ran and examine the relevant GitHub Actions logs.

Socket advises treating a completed run as successful credential exfiltration when the workflow contains the relevant collection logic. Organisations should also review repository audit logs for unexpected workflow additions and rapid commits across multiple repositories.

3. Revoke and rotate exposed credentials

If the workflow references GitHub Actions secrets, replace the affected secrets and revoke access tokens where appropriate.

If the workflow searches repository files and Git history, examine both the current working tree and historical commits. Rotate or revoke every potentially exposed credential, including keys that were removed from files in earlier commits.

Revocation is preferable for tokens that support it because it invalidates the compromised credential rather than merely replacing a value in a configuration system.

4. Investigate cloud activity

For potentially exposed AWS credentials, review CloudTrail records covering the suspected exposure period and the time afterward.

Look for unexpected API calls, unfamiliar access patterns, newly created IAM users or access keys, and activity in unexpected regions. The precise investigation should reflect the permissions of the exposed credentials and the cloud services in use.

5. Remove the malicious workflow across affected repositories

Remove the malicious file and revert the associated commit wherever it appears, including organisation-owned repositories and relevant forks.

Check every repository that the compromised account could modify. Removing the workflow from only one project may leave other repositories exposed.

6. Secure the compromised maintainer account

Review and revoke active sessions, personal access tokens, OAuth grants and SSH keys associated with the compromised account as appropriate.

Re-establish account access securely, enforce phishing-resistant multi-factor authentication where available and review the account's repository permissions.

7. Review network indicators

Search network and egress logs for connections to the reported destination, 193.32.204[.]199, including traffic originating from self-hosted CI/CD runners.

Use the indicator as part of a wider investigation rather than relying on it as the sole detection method.

8. Strengthen secret and workflow controls

Socket recommends enabling GitHub secret scanning with push protection and requiring approval for workflow runs from outside collaborators.

Organisations should also restrict write access to repositories, review changes to workflow files and investigate unexpected automation changes before allowing them to execute.

Indicators of Compromise

Socket's report identifies several indicators that security teams can use during their investigation.

Security teams should search for these indicators across repositories, forks, organisation audit logs and CI/CD execution records. The presence of the malicious workflow is especially significant because a repository may be exposed even if its current files do not visibly contain any credentials.

The investigation should also establish whether exposed credentials remain valid and whether they were used after the suspected compromise.

What Developers and Open-Source Maintainers Should Learn

GhostAction reinforces several practical security principles for development teams.

First, repository access is a security boundary. A compromised maintainer account can affect more than one project, particularly when it has write access to organisational repositories and forks.

Second, automation must be reviewed as code. GitHub Actions workflows can execute commands and access credentials. A workflow described as a security audit should not be trusted solely because of its name or location.

Third, secret removal is not credential revocation. Historical commits can preserve sensitive values after developers delete them from current files. Credentials that have been exposed should be invalidated and replaced.

Fourth, security monitoring should cover identity, code and execution. Reviewing repository changes, workflow permissions, audit events and cloud activity provides a more complete picture than checking source files alone.

These lessons are relevant to organisations of all sizes, from independent open-source maintainers to enterprises that rely on automated builds and deployment pipelines.

Conclusion

The latest GhostAction wave demonstrates how compromised maintainer accounts and malicious GitHub Actions workflows can be used to collect credentials from both CI/CD environments and repository history.

Socket's findings show that the exposure can extend beyond a developer's personal projects to organisation-owned repositories and forks. The added search for cloud and AI service credentials broadens the range of systems that may require investigation.

Although Socket reported no malicious PyPI or crates.io package releases resulting from this activity at the time of publication, successful workflow execution and credential collection remain serious security concerns.

For defenders, the immediate priority is to identify the malicious workflow, determine whether it ran, remove it from every affected repository, revoke or rotate exposed credentials and investigate possible downstream activity.

The wider takeaway is clear: protecting the software supply chain requires continuous attention to developer identity, automation permissions and secrets throughout their lifecycle, including credentials that may remain hidden in historical commits.