Overview
The GhostAction supply-chain campaign has evolved from malicious GitHub Actions workflows into a broader attack against open-source developers and the systems they use. The latest activity combines phishing, stolen GitHub OAuth tokens, malicious repository changes and a credential stealer disguised as a legitimate font file. Researchers have identified 94 repositories belonging to 66 owners containing the second-stage components. What makes this development particularly concerning is that the attack no longer depends entirely on GitHub’s CI/CD infrastructure. The repository itself can become the delivery mechanism to compromise the developer workstation.
From CI/CD Compromise to Developer Workstations
The original GhostAction campaign abused GitHub Actions workflows to harvest secrets from compromised repositories. After GitHub introduced controls that prevented the malicious workflow from running, the attackers introduced another mechanism that operates outside the GitHub Actions runner. Researchers observed repositories containing a Visual Studio Code tasks.json configuration with a runOn: folderOpen trigger. When the repository is opened in VS Code, the task can automatically execute. This creates a significant change in the attack path. A developer does not necessarily need to execute a suspicious script manually. Opening a compromised project can become the trigger. The researchers noted that the second-stage technique appeared six days after GitHub began blocking the malicious workflow. That timing is notable, although the researchers explicitly cautioned that it cannot be concluded that the GitHub control directly caused the change.
The Malware Was Disguised as a Font
The campaign also demonstrates how attackers can hide malicious content inside files that appear completely ordinary. A file named fa-solid-400.woff2 was placed under public/fonts/, making it look like a standard Font Awesome font resource. Instead, the file contained an information-stealing payload designed to search for valuable developer credentials. The targeted information reportedly includes AWS credentials, PyPI and npm tokens, Git credentials, Kubernetes credentials, SSH private keys and credentials associated with AI services such as Anthropic Claude and Google Gemini. This is particularly significant because developers frequently have access to credentials that extend far beyond their local workstation. A single compromised development environment can therefore provide a pathway into cloud infrastructure, package registries, source-code repositories, Kubernetes environments and AI platforms.
Persistence Continues After the Workflow Is Removed
The second-stage malware does more than collect credentials. Researchers observed it installing a cron job that executes attacker-supplied code every five minutes, creating persistence on the developer’s system. The stolen information is then sent to attacker-controlled infrastructure. This changes the incident-response equation. Removing the malicious GitHub Actions workflow may stop one part of the attack, but it does not necessarily clean systems that have already cloned or opened the affected repository. A compromised repository can therefore outlive the security control that originally detected it.
OAuth Turns Identity Into the Supply Chain
The campaign also uses a convincing phishing operation to target open-source maintainers. A fake GitHub security notification directs victims to a lookalike website. The phishing infrastructure acts as a reverse proxy, allowing attackers to capture credentials and two-factor authentication information while interacting with the legitimate GitHub authentication process. The campaign goes further by abusing GitHub’s OAuth device flow. The malicious process attempts to obtain an OAuth token with permissions capable of reading and modifying repositories and workflows, as well as accessing organisational information. This is more dangerous than simply stealing a password. An OAuth token becomes a reusable delegated identity. Once obtained, it can allow attackers to operate through legitimate APIs with permissions associated with the victim’s account.
Trust Must Follow the Entire Development Lifecycle
GhostAction demonstrates why software supply-chain security cannot stop at repository scanning or CI/CD protection. Controls need to consider the complete lifecycle:
repository → clone → developer workstation → IDE → credentials → CI/CD → cloud infrastructure
Every transition creates another trust boundary. Repository owners should audit unexpected workflow and configuration changes, review OAuth applications and tokens, and rotate credentials that may have been accessible to compromised workflows or development environments. Where compromise is suspected, credential rotation should be performed from a clean system rather than assuming that removing the repository changes is sufficient. Developers who have cloned affected repositories also become part of the incident scope.
Expert in the Cloud Insight
GhostAction demonstrates a critical shift in software supply-chain attacks. The attacker no longer needs to compromise the build server alone. The developer, the repository, the IDE and the credentials can all become components of the attack chain. The fake font is particularly revealing because its appearance is almost irrelevant. What matters is how the file is trusted and what happens when the surrounding development environment processes it. Modern development security therefore needs to evaluate behaviour and execution paths, not simply file extensions, repository reputation or the presence of signed software. A trusted repository can deliver an untrusted payload, and a trusted development tool can execute it. Trust must be continuously validated across the entire software lifecycle.
Leave a Reply