The GhostAction supply-chain campaign has returned with a large-scale credential-theft operation targeting GitHub repositories. Attackers reportedly compromised developer accounts and injected malicious GitHub Actions workflows disguised as security audits. These workflows searched repository files and Git history for sensitive credentials, then exfiltrated the data to an attacker-controlled IP address. More than 500 GitHub accounts have reportedly been linked to the activity, with tens of thousands of repositories potentially affected.
GitHub Actions is widely used to automate software development tasks, including testing, building, deployment, and security checks. Developers often rely on workflow files to run these processes automatically whenever code changes or a manual trigger occurs.
But what happens when an attacker gains access to a developer's account and adds a workflow that looks like a legitimate security check?
That is the technique at the centre of the renewed GhostAction campaign.
According to the report published by The Hacker News on October 9, 2026, attackers used compromised maintainer accounts to introduce malicious GitHub Actions workflows into hundreds of repositories in concentrated bursts. The wider campaign has reportedly affected tens of thousands of repositories.
The danger is not limited to source code. Repositories and their build environments can contain credentials that provide access to cloud infrastructure, software publishing systems, AI services, and other business platforms. A malicious workflow can turn these development environments into automated credential-harvesting opportunities.
Security researchers from StepSecurity reported malicious workflow activity involving two prominent open-source maintainer accounts.
The first account belonged to Takashi Kitao, the author of the Pyxel game engine. According to the report, the compromised account pushed a malicious workflow to 27 repositories beginning at 13:20 UTC.
Approximately eight hours later, another maintainer account, associated with Henry Wu (henrywoo), was used to distribute the same workflow to 318 repositories within a 16-minute period.
The workflows used names that could appear legitimate during a quick review:
security-audit.yml
github_actions_security.yml
Their security-themed names were part of the deception. Instead of simply auditing code, the workflows were designed to search for sensitive credentials and send the results to an external endpoint.
Socket reported that, by October 9, 2026, it had identified more than 500 GitHub accounts committing the malicious workflow to tens of thousands of repositories since October 7.
The activity is associated with GhostAction, a campaign first publicly reported in September 2025. The earlier campaign reportedly affected 817 repositories across 327 GitHub users and resulted in the theft of 3,325 secrets.
The renewed activity demonstrates how compromising a trusted developer account can provide an attacker with a route to distribute malicious changes across many projects.
The reported attack chain combines account compromise, repository reconnaissance, workflow injection, automated secret discovery, and data exfiltration.
The attacker first gains access to a developer or repository maintainer account. The report identifies a leaked personal access token (PAT), potentially obtained from infostealer logs or credential dumps, as a likely initial access method.
The exact initial compromise method was not conclusively established in the supplied report.
A compromised account can allow an attacker to make changes that appear to come from a trusted maintainer. This makes the activity harder to identify through a simple review of the author's name.
Once access is obtained, the attacker examines repository contents and workflow files to identify potential secrets and understand where the malicious workflow can be introduced.
The objective is not necessarily to exploit a vulnerability in the application itself. Instead, the attacker abuses the trust placed in the developer account and the automation platform.
This is a significant supply-chain risk: the attacker can manipulate the process used to build, test, or deploy software.
The attacker adds a workflow disguised as a security audit to the repository's default branch.
According to StepSecurity, the workflow can be triggered manually through workflow_dispatch or by a push event that is not restricted to particular branches or tags.
It also uses fetch-depth: 0, which checks out the complete Git history rather than only the latest revision. That matters because credentials accidentally committed in the past may remain recoverable from historical commits even after being removed from the current files.
The workflow then performs its credential collection and exfiltration tasks.
The malicious workflow reportedly performs several operations:
Collects named GitHub Actions secrets identified during reconnaissance.
Searches the current working tree for 13 patterns associated with credentials and API keys.
Searches the complete Git history for the same credential patterns.
Pairs AWS access key IDs with corresponding secret access keys.
The targeted information includes cloud credentials, source-control tokens, AI-service API keys, and other sensitive secrets.
Searching Git history is particularly important. Developers sometimes commit a credential accidentally, remove it in a later commit, and assume the issue has been resolved. However, deleting a secret from the latest version does not remove it from earlier commits.
If an attacker can access that history, the previously exposed credential may still be recovered.
The workflow sends collected information to a hard-coded external IP address using curl over plain HTTP.
The IP address reported in the article is:
193.32.204[.]199
Plain HTTP does not provide transport encryption, making the destination and traffic worth investigating when observed in the relevant context. However, defenders should correlate this indicator with workflow execution logs, process activity, and network telemetry rather than treating a single match as the only evidence needed to establish compromise.
The workflow reportedly returns a repository identifier even when no credentials are discovered. This can also help the operator map repositories and execution environments accessible through compromised accounts.
The campaign targets much more than GitHub tokens. Credentials exposed through repository files, workflow secrets, and Git history can provide access to systems beyond the original project.
Reportedly targeted credential types include:
Cloud infrastructure: AWS access keys, Azure credentials, Google Cloud and Firebase credentials.
Source-control platforms: GitHub and GitLab tokens.
AI services: Anthropic, OpenAI, and OpenRouter API keys.
Package publishing: npm and PyPI credentials.
Container registries: DockerHub and GitHub Container Registry (GHCR) credentials.
Communication platforms: Slack, Discord, and Telegram bot tokens.
Other services: SSH private keys, database credentials, FTP credentials, and Cloudflare keys.
The potential impact depends on each credential's permissions, validity, and exposure. A stolen token with read-only access may have a limited effect, while an active credential with deployment or administrative privileges could provide a route to more serious compromise.
The key risk is that a single compromised developer account may expose credentials belonging to multiple services and environments.
The campaign also highlights the risk posed by repository forks and downstream copies.
Socket reported that 279 forks in the henrywoo namespace contained the malicious workflow. If GitHub Actions is enabled and the relevant triggers are activated, later pushes may cause the workflow to execute and harvest credentials.
Downstream repositories can remain exposed if they inherit the workflow from an affected upstream project or synchronize with a compromised source.
Private repositories are especially sensitive because they may contain internal configuration, deployment secrets, and code that is not publicly accessible. Their risk depends on their workflow configuration, permissions, and the credentials available to the workflow.
For defenders, checking only the original public repository is therefore insufficient. Forks, mirrors, private copies, and other downstream projects must also be considered during remediation.
The supplied report also describes an earlier incident involving the kuafuai/DevOpsGPT repository.
On August 30, 2026, threat actors reportedly modified the repository to embed an XMRig cryptocurrency miner in the project's Docker image.
The article states that, at the time of publication, researchers had not identified malicious package releases published using the compromised publishing credentials.
This distinction is important: compromising a repository or stealing publishing credentials does not automatically mean a malicious package has been released. Investigators should establish what actions actually occurred rather than assume every possible consequence has happened.
For SOC analysts and incident responders, this campaign offers several useful investigation paths. The following are recommended defensive checks based on the reported attack technique, not a claim that every environment will contain all these indicators.
Search repositories and all relevant branches for:
security-audit.yml
github_actions_security.yml
Review unfamiliar workflow files, unexpected additions, and modifications made since August 31, 2026, the start date highlighted in the report.
Check the commit history and identify the account responsible for each change. A trusted username alone is not proof that a change is legitimate.
Examine workflow runs for unexpected executions, particularly those associated with workflow_dispatch or broad push triggers.
Record the workflow name, run time, triggering event, commit SHA, actor, and affected repository. Compare these details with legitimate development and release activity.
Investigate runs that appeared shortly after suspicious commits or changes to workflow permissions.
Look for connections from GitHub Actions runners or associated execution environments to:
193.32.204[.]199
Where telemetry is available, correlate the connection with workflow-run timestamps and process activity involving curl.
An IP match is an investigative lead, not a complete incident conclusion. Establish whether the connection originated from a relevant workflow and whether sensitive data may have been transmitted.
Determine which credentials were accessible to the affected workflow, including:
GitHub Actions secrets.
Credentials stored in repository files.
Secrets present in Git history.
Cloud and deployment credentials.
Package-publishing tokens.
AI-service and SaaS API keys.
Avoid placing exposed secret values directly into incident tickets or investigation notes. Record the credential type, location, owner, permissions, and rotation status using approved secure handling procedures.
Check forks, private repositories, mirrors, and dependent projects for copies of the malicious workflow.
If credentials were accessible to a malicious run, investigate whether they were used afterward. Depending on the credential type, this may include cloud audit logs, source-control activity, package publication records, API usage, and changes to deployment infrastructure.
Do not limit the investigation to the original repository: the exposed credentials may grant access to unrelated services.
If a repository contains the reported malicious workflow, treat it as a potential compromise and follow your organization's incident-response process.
Contain the workflow: Disable or otherwise prevent further malicious executions while preserving relevant evidence.
Revoke compromised access: Revoke the affected personal access token or other compromised GitHub credentials, and review the account's sessions and access.
Rotate exposed secrets: Rotate credentials that the workflow could access, prioritizing privileged cloud, deployment, source-control, and publishing credentials.
Remove malicious changes: Delete the malicious workflow from affected branches and investigate forks, mirrors, and downstream repositories.
Review audit records: Examine workflow runs, repository changes, and service audit logs for unauthorized access or follow-on activity.
Validate recovery: Confirm that the malicious workflow cannot execute again and that exposed credentials have been replaced and tested.
Strengthen controls: Apply least-privilege permissions to workflows, restrict unnecessary access to secrets, review third-party actions, and require appropriate approval for sensitive workflow changes.
Simply deleting the workflow is not sufficient. If a malicious run already accessed a secret, that credential must be treated as potentially exposed even after the workflow has been removed.
The following indicators are drawn from the supplied report. They should be used alongside contextual evidence and your organization's threat-intelligence procedures.
Searches for 13 patterns associated with credentials and API keys.
Inspection of the current working tree and full Git history.
Collection of named GitHub Actions secrets.
Pairing of AWS access key IDs with corresponding secret access keys.
Use of curl to transmit collected data to the reported external IP address.
Workflow changes made through compromised maintainer accounts.
Unexpected workflow execution across multiple repositories or forks.
Important: Workflow names, trigger settings, and fetch-depth: 0 are not inherently malicious. Confirm whether the file contents, commit history, execution behaviour, and network activity match the reported campaign before declaring an indicator a confirmed compromise.
The supplied report does not provide file hashes or a complete set of malicious payload contents, so no hashes are included here.
GhostAction illustrates how software supply-chain attacks can exploit trust rather than rely exclusively on software vulnerabilities. A compromised maintainer account can introduce a seemingly legitimate automation workflow, and that workflow can search repositories and historical commits for credentials that unlock other systems.
For development teams, the lesson is straightforward: a trusted repository is not automatically a safe execution environment. Workflow changes deserve careful review, secrets should be tightly scoped, and credentials that may have been exposed must be rotated rather than merely deleted from source code.
For SOC teams, the investigation should connect repository changes, workflow executions, outbound network activity, credential exposure, and potential downstream misuse. Detecting the malicious file is only the first step; determining what it accessed and what happened afterward is essential to understanding the full impact.
Continue reading
Cyber News
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker that reportedly combined automat...
Cyber News
A malware campaign called Midnight Mimosa has been discovered on low-cost Android smartphones, where malicious software is embedded directly into device firmware. According to Bitd...
Cyber News
Cybercriminals are abusing Google search advertisements and legitimate Bing redirect URLs to distribute a fake Claude installer targeting macOS users. The campaign, tracked by Push...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
