GhostAction attackers hide credential stealers in fake fonts across GitHub

The threat actor behind the GhostAction supply chain attack has shifted tactics, moving from injecting malicious workflows into GitHub projects to phishing developers directly. In a campaign detailed by OpenSourceMalware on October 19, 2026, the group deployed a credential stealer disguised as a font file across 94 compromised repositories. This evolution allows the attackers to harvest sensitive data even when GitHub blocks their automated workflows.

What happened

The attackers registered the domain "my-github[.]com" on October 9, 2026, pointing it to the IP address 193.32.204[.]199. This same IP serves as the exfiltration endpoint for data stolen via malicious GitHub Actions. On the day of registration, the group sent phishing emails impersonating GitHub security alerts to open-source maintainers. These messages warned of suspicious logins from Moscow and directed victims to a fake login page. This page acted as a reverse proxy, capturing passwords and two-factor authentication codes while silently authorizing an OAuth application with broad permissions to modify workflows and read organization data.

Once access was secured, the attackers injected malicious files into repositories. The campaign includes a second-stage component designed to persist on developer machines. This involves committing a Visual Studio Code tasks configuration that triggers automatically when a folder is opened, a fake font file containing a stealer payload, and a backup GitHub Actions workflow. The font file, named "fa-solid-400.woff2," mimics a legitimate asset but actually harvests AWS keys, PyPI tokens, npm tokens, Git logins, Kubernetes credentials, SSH keys, and AI provider credentials for Anthropic Claude and Google Gemini.

This second stage installs a cron job that executes attacker-supplied code every five minutes if the initial stealer fails to run. The collected data is transmitted over plain HTTP on port 8080. OpenSourceMalware identified 94 repositories belonging to 66 owners that contain this second-stage component. Fifteen of these repositories have since been deleted, renamed, or made private. Most of the affected projects appear abandoned, with 65 of the 79 accessible repositories showing no commits for over a year.

Key details

• The attackers registered "my-github[.]com" on October 9, 2026, using the same IP address as their previous exfiltration infrastructure.
• Phishing emails impersonated GitHub security alerts, using a reverse proxy to steal credentials and authorize OAuth apps without user consent.
• A fake font file named "fa-solid-400.woff2" contains a stealer targeting cloud keys, tokens, and AI provider credentials.
• The malware installs a cron job that runs every five minutes to ensure persistence and continuous data exfiltration.
• 94 repositories across 66 owners were compromised, with many projects appearing abandoned or inactive for over a year.
• GitHub began blocking the original malicious workflows on October 9, prompting the shift to client-side persistence methods.

Background

Supply chain attacks target the software development lifecycle by compromising trusted components or tools. In this case, the attackers exploited the trust developers place in open-source repositories and integrated development environments like Visual Studio Code. By disguising malware as a common font file, they bypassed casual inspection. The use of OAuth device flow phishing is particularly dangerous because it automates the authorization process, granting attackers API tokens that can modify repository settings and inject further malicious code.

Cron jobs are scheduled tasks that run at fixed intervals on Unix-like systems. While essential for automation, they can be abused by attackers to maintain persistent access to a system. If a malicious script is added to a user's crontab, it can execute repeatedly without further interaction, ensuring that stolen data continues to be sent to the attacker's server even if the initial infection vector is removed.

Why it matters

For teams running their own software, this incident highlights the risk of relying solely on platform-level security controls. GitHub’s ability to block malicious workflows did not stop the attackers; they simply moved to a method that operates on the developer's local machine. This means that even if your CI/CD pipeline is secure, compromised dependencies or cloned repositories can introduce malware that steals credentials from your local environment. These credentials often include access to production infrastructure, making local hygiene critical for overall security.

The targeting of abandoned or inactive repositories is a significant concern for organizations that fork or depend on older open-source projects. These projects may lack active maintainers who can quickly identify and remove malicious commits. If your team uses such libraries, you may inadvertently introduce stealthy backdoors into your development workflow. The use of plain HTTP for exfiltration also suggests that network monitoring could detect these attacks, but only if traffic to suspicious IPs is closely watched.

What you can do

• Revoke all GitHub access tokens and change passwords from a known clean device immediately if you suspect exposure.
• Audit your repositories for unusual files, particularly in public asset folders like fonts, and check for unexpected VS Code task configurations.
• Rotate all credentials that may have been exposed, including AWS keys, npm tokens, and SSH keys, especially those stored in environment variables.
• Monitor your local cron jobs and scheduled tasks for any unfamiliar entries that run frequently or connect to external servers.
• Alert any users who have cloned or forked the affected repositories to ensure they do not propagate the malicious code.
• Implement network monitoring to flag outbound HTTP traffic to unknown IPs or ports, such as port 8080, which was used in this campaign.