Trending: On-device modelsSearch
iHeartGeek
iTECH

GhostAction hides credential stealer in 94 GitHub repositories

GhostAction is hiding a credential stealer in fake font files and Visual Studio Code triggers across 94 GitHub repositories.

Terminal directory listings representing the technical threat environment in a GhostAction cybersecurity story

GhostAction operators are expanding a GitHub supply-chain campaign with a credential stealer hidden inside a fake font file, according to reporting by The Hacker News and the OpenSourceMalware research team.12 The second-stage malware has been identified in 94 repositories belonging to 66 owners, adding a persistence route that does not depend on GitHub Actions running successfully.1

The campaign initially compromised projects by injecting malicious GitHub Actions workflows. The newer operation adds GitHub-themed phishing and files that can trigger locally when a developer opens a project in Visual Studio Code.1 That shift matters because a repository can remain dangerous even after GitHub blocks the malicious workflow from executing on its runners.

How the fake font attack works

The campaign uses a `public/fonts/fa-solid-400.woff2` file to conceal an infostealer payload. The filename resembles a legitimate Font Awesome file, but the file contains code designed to harvest AWS keys, PyPI and npm tokens, Git credentials, Kubernetes credentials, SSH private keys, and AI-provider credentials for services including Anthropic Claude and Google Gemini.1

The same second-stage bundle includes a Visual Studio Code `tasks.json` file with a `runOn: folderOpen` trigger. Opening an affected folder can therefore launch the stealer without the developer deliberately running a suspicious script.1 The bundle also contains a fallback GitHub Actions workflow and a cron job that runs attacker-supplied code every five minutes after installation.

OpenSourceMalware said that 15 of the 94 affected repositories have since been deleted, renamed or made private. Of the remaining accessible repositories, 65 had not received a commit in more than a year, which may make them less visible to their owners while leaving clones and downstream projects exposed.1

The phishing route

The attackers also registered `my-github[.]com`, a domain designed to resemble GitHub infrastructure. A phishing email impersonating a GitHub security alert reportedly sent users to a reverse-proxy login page that harvested passwords and two-factor authentication codes.12

The page was also designed to authorise a GitHub OAuth device flow. GitHub's documentation shows that OAuth device flows can grant an application access based on the scopes approved by the user; in this case, the requested `repo`, `workflow` and `read:org` permissions could expose repositories, let an attacker modify workflow files and reveal organisation data.3

The campaign's infrastructure and attribution remain uncertain. OpenSourceMalware said the `my-github[.]com` domain and a similar GitLab-themed domain do not share enough registrar, DNS, certificate or account evidence to connect them conclusively.1 The reporting also notes that the stealer has technical weaknesses, but those flaws do not make an exposed developer account safe.

What developers should do

Developers who may have opened an affected repository should revoke GitHub access and tokens from a clean device, change passwords, audit repositories and rotate every credential the workflows could reach.1 They should also alert anyone who cloned the repositories and inspect projects for unexpected workflow files, `tasks.json` triggers, unfamiliar font files and newly authorised OAuth applications.

The hero image is an abstract terminal photograph by Pixabay, supplied through Pexels. It illustrates the technical setting rather than depicting the GhostAction malware itself.4

Our opinion

This is a useful warning because it shows why supply-chain security cannot stop at the hosted CI runner. Blocking a malicious workflow is valuable, but the same campaign can move into phishing, OAuth abuse and files that execute when a developer opens a project locally. That combination puts both active maintainers and forgotten repositories in the firing line. The practical lesson is blunt: treat repository contents, editor automation and OAuth permissions as part of the attack surface, not as separate security concerns.