A reported new phase of the GhostAction campaign shows how software supply chain threats are evolving on developer platforms. According to reporting cited from security researchers, attackers associated with GhostAction have moved beyond planting malicious GitHub Actions workflows and are now also targeting open-source developers with phishing and credential theft malware disguised as a font file.

While the technical details come from security research rather than an official platform-wide incident notice, the development is relevant for European companies that build software internally, depend on open-source components, or use GitHub repositories and automation workflows in day-to-day operations.

What happened

The reported activity links the GhostAction threat actor to a broader campaign on GitHub. Earlier activity focused on injecting malicious GitHub Actions workflows into compromised projects. The latest reported shift adds two more elements:

• Phishing of open-source developers to obtain access or credentials.
• Delivery of credential-stealing malware hidden in a file presented as a font.

The source report says the malicious files were identified in 94 GitHub repositories. Based on the information available, this should be treated as a security research finding about an active campaign, not as evidence that every repository user was compromised.

The wider pattern is important: attackers are not only targeting endpoints or email inboxes, but also the tools developers use to write, store, test and deploy code. That makes GitHub repositories, CI/CD pipelines, access tokens and developer accounts attractive entry points.

Why it matters for European businesses

For many SMEs and digital teams, GitHub is not just a code hosting platform. It is part of the delivery chain for websites, e-commerce platforms, SaaS tools, APIs, internal automation and customer-facing applications. A compromise at repository or workflow level can affect:

• source code integrity
• deployment pipelines
• access tokens and secrets
• production infrastructure connected to CI/CD
• customer data and business systems if credentials are reused or over-permissioned

This is especially relevant for businesses that rely on open-source packages or public repositories maintained by external contributors. Even when a company is not directly targeted, a poisoned dependency, compromised maintainer account or malicious workflow can create downstream risk.

For European organisations, the business impact can go beyond technical cleanup. Depending on the nature of the compromise, companies may face service disruption, exposure of internal credentials, incident response costs, contractual issues with customers, and possible data protection implications if personal data is affected.

Who may be affected

The risks are not limited to software vendors. Organisations most likely to be exposed include:

• SMEs with in-house development teams using GitHub for application development or deployment automation.
• E-commerce businesses running custom storefronts, plugins, integrations or CI/CD-based release processes.
• Digital agencies and IT service providers managing multiple client repositories and deployment environments.
• SaaS and platform businesses where developer credentials can provide access to cloud systems and production environments.
• Companies using open-source dependencies without strong controls for verifying repository trust and workflow behaviour.

Even non-technical businesses can be indirectly affected if a software supplier, agency or managed service provider uses compromised repositories or developer accounts.

What companies should consider

Businesses using GitHub or similar development platforms should review software supply chain controls and developer account protections. Practical steps may include:

• Review GitHub Actions usage and limit workflows to trusted repositories, trusted actions and approved contributors where possible.
• Audit secrets and tokens stored in repositories and CI/CD systems. Rotate credentials if there is any suspicion of exposure.
• Apply least-privilege access to developer accounts, service accounts and automation tokens so that one compromised credential does not expose production systems.
• Enforce strong authentication for developer platforms, including phishing-resistant multi-factor authentication where feasible.
• Train developers to verify unexpected files and contribution requests, especially when attachments or assets such as fonts, images or build files appear unrelated to normal project activity.
• Monitor repository and workflow changes for unusual commits, new workflow files, altered permissions or unexplained build behaviour.
• Check supplier and agency practices if external teams maintain code or deployments on the company’s behalf.

For organisations with formal security or compliance obligations, this incident is also a reminder to include source code platforms and build pipelines in broader risk assessments. Developer tooling is now part of the business attack surface, not a separate technical concern.

Although the available information describes a specific campaign, the larger lesson is broader: attackers increasingly target trust relationships inside software development. European businesses that depend on modern web delivery, automation and cloud-based development should treat repository security and CI/CD governance as operational priorities.