Massive Supply Chain Attack Targets Tens of Thousands of GitHub Repositories

In a sophisticated and alarming development for the software development community, security researchers at Socket have uncovered a large-scale supply chain attack that has successfully infiltrated tens of thousands of GitHub repositories. The breach, which impacts both individual and organization-owned repositories, underscores the ongoing vulnerability of automated development workflows. Among the high-profile entities identified as running compromised packages is ride-hailing giant Uber, highlighting the potential severity and reach of this malicious campaign.

The attack, which leverages the GitHub Actions platform to execute its payload, bears a striking resemblance to the "GhostAction" campaign—a series of malicious activities first identified by GitGuardian in September 2025. Following its initial discovery, GhostAction saw a resurgence in October 2026, and the current incident appears to be an evolution of those earlier efforts. By exploiting the inherent trust placed in automated CI/CD (Continuous Integration/Continuous Deployment) pipelines, the perpetrators have managed to compromise a vast number of projects with relative ease, raising significant concerns about the security posture of the global software ecosystem.

Malicious Workflows Spread Through Compromised GitHub Accounts

The mechanics of this latest campaign are both simple and highly effective. On October 8, 2026, researchers identified two specific GitHub accounts—identified as ‘henrywoo’ and ‘kitao’—that were actively pushing malicious GitHub Actions workflows to hundreds of repositories where they held sufficient permissions to modify files.

A GitHub Action is essentially an automated task triggered by specific events within a repository, such as a code push, a pull request, or a scheduled time. These workflows are integral to modern software development, as they automate essential functions like running test suites, building binary artifacts, and deploying applications to cloud environments. By abusing this functionality, the attackers were able to ensure their malicious code would execute automatically whenever the workflow was triggered.

The malicious file, cleverly disguised as .github/workflows/security-audit.yml, was introduced to target repositories through seemingly routine commits. The commit messages associated with these additions—such as "Add security audit workflow" and "Update security audit workflow"—were carefully crafted to blend into the normal development history of a project. To a busy developer or an automated monitoring tool, these labels suggest a proactive approach to security rather than a malicious intrusion.

Despite its deceptive branding, the workflow performs no actual security audits. Instead, its primary function is the surreptitious theft of sensitive credentials. Once executed, the script harvests tokens and secrets from the affected repository and transmits them to an external, attacker-controlled server located at 193.32.204[.]199 over unencrypted HTTP. Because the workflow mimics a legitimate tool, it often avoids triggering standard security alerts, allowing it to persist undetected within the repository’s automated processes.

The scale of this operation is significant. Socket researchers found the malicious file in tens of thousands of repositories, demonstrating a systematic, automated approach to propagation. The attackers did not discriminate based on the popularity, commercial value, or current activity levels of a project. Even repositories that had remained dormant for over a decade were targeted, suggesting that the perpetrators used automated scripts to enumerate and exploit every repository accessible to the compromised accounts rather than manually selecting high-value targets.

Expanding the Capabilities of GhostAction

While this incident is clearly a variation of the GhostAction campaign, Socket’s analysis indicates a concerning expansion of the attackers’ capabilities. Previous iterations of GhostAction were primarily focused on harvesting secrets that were explicitly stored within GitHub Actions environments, such as API keys and access tokens configured for CI/CD pipelines. These credentials are often used to authorize workflows to interact with third-party services, and their theft can provide attackers with unauthorized access to those services.

The new variant, however, significantly increases the potential impact by implementing a more aggressive discovery mechanism. The malicious workflow now systematically scans the repository’s files and its entire Git history for potential credentials using regular-expression patterns. This capability is particularly dangerous because it can uncover sensitive information that developers may have accidentally committed to the source code, buried in configuration files, or left in previous versions of files that have since been deleted.

Because Git is a version-control system designed to track the entire history of a project, deleting a file or removing a secret from the latest commit does not necessarily remove it from the repository’s history. An attacker with access to the repository can clone the history and easily extract secrets that were once committed, even if they were removed years ago. By searching this "historical data," the attackers are casting a much wider net, potentially uncovering long-forgotten credentials for cloud providers, AI services, and critical infrastructure. The exposure of such information could lead to broad compromises, granting the attackers deep access to private cloud environments, hosted applications, and the various third-party services that modern businesses rely on to operate.

Ongoing Risks to the Development Ecosystem

As of October 9, 2026, the malicious workflow remained active on the default branches of several examined repositories, including public-facing projects like uber/athenadriver and kitao/pyxel. Socket researchers confirmed that the workflow was not merely present but had successfully executed in these repositories, meaning the credential-harvesting process was fully functional.

The presence of the script in the default branch is a critical indicator of the risk, as it ensures that any developer or automated process interacting with the main code of the project will trigger the malicious workflow. While the researchers noted that they had not, at the time of their report, observed any malicious package versions being published to common registries like PyPI or crates.io as a direct result of this campaign, this does not mean the stolen credentials have remained unused.

The lack of follow-on malicious package releases simply indicates that the current phase of the operation is focused on intelligence gathering and credential exfiltration. Once an attacker possesses a stolen set of cloud or service credentials, they have a wide array of options for further exploitation. They could potentially gain access to the private infrastructure of the organizations involved, inject further malicious code into legitimate software releases, or use the stolen credentials to pivot into even more sensitive internal systems.

The situation remains fluid, and the full extent of the compromise is still being evaluated. For organizations and individual developers, the event serves as a stark reminder of the security risks inherent in the modern software supply chain. Automated tools, while essential for efficiency, can become powerful conduits for attackers if they are not properly audited and secured.

As security teams work to identify and remove the malicious workflows from affected repositories, the incident highlights the need for more rigorous access controls and the importance of regularly auditing CI/CD configurations. In an environment where a single malicious commit can compromise tens of thousands of projects, the ability to detect and remediate such threats quickly is paramount. For now, the software development community must remain vigilant, treating every automated workflow as a potential entry point for attackers and ensuring that sensitive credentials are never stored in plain text, whether in current code or in the deep history of a repository.