A reported surge in the GhostAction campaign has highlighted a familiar but serious risk for businesses that rely on GitHub for software development and deployment: compromised developer accounts can quickly become a route to exposed secrets, CI pipeline abuse and wider software supply chain risk.

According to reporting citing GitGuardian, the campaign intensified on 8 and 9 October 2026, targeting more than 30,000 repositories across roughly 3,000 users and organisations. The researchers said about 1,900 GitHub accounts were compromised and that the attackers attempted to extract secrets from public repositories' continuous integration environments.

What happened

Based on the available report, GhostAction is a credential-theft operation focused on GitHub accounts and repositories. The latest activity reportedly involved a sharp increase in targeting, with attackers using access to compromised accounts to reach a large number of repositories.

The researchers said the campaign attempted to extract 3,174 secrets from public repositories' CI environments. In practice, those secrets can include API keys, tokens, cloud credentials or other access data used by automated build and deployment workflows.

At the time of the source report, these details were attributed to GitGuardian's research. Businesses should treat the figures as reported by the security company unless independently confirmed by GitHub or affected organisations.

Why it matters for European businesses

For many SMEs and digital teams, GitHub is not just a code hosting platform. It is often part of the operational backbone for websites, e-commerce systems, SaaS products, internal tools and automated deployments. If an attacker gains access to a developer account or CI secrets, the impact can go beyond source code exposure.

Potential business risks include:

• Unauthorised code changes that affect websites, applications or customer-facing services.
• Exposure of secrets such as cloud credentials, deployment tokens or third-party API keys.
• Supply chain risk if attackers tamper with build pipelines or software packages.
• Service disruption if compromised credentials are used to alter infrastructure or deployment settings.
• Compliance and incident response pressure where personal data, customer systems or regulated environments are connected to affected development workflows.

This is especially relevant for European companies that outsource development, use multiple contractors, or run distributed engineering teams. In those environments, identity management and repository access can become fragmented, increasing the attack surface.

Who may be affected

The immediate risk is highest for organisations that use GitHub to manage public repositories, CI workflows and automated deployments. However, the broader issue affects a wider set of business users:

• Software companies and SaaS providers managing active repositories and release pipelines.
• E-commerce businesses whose storefronts, integrations or plugins are deployed through GitHub-linked workflows.
• Digital agencies and development partners handling client repositories and shared credentials.
• SMEs with lean IT teams that rely on default GitHub settings or lack formal secrets management.
• Regulated businesses where compromised development infrastructure could create security, audit or data protection consequences.

Even businesses with private codebases should pay attention. Campaigns that start with public repositories often expose weaknesses in account security, token hygiene and workflow design that may also exist in private development environments.

What companies should consider

While the source report provides only limited technical detail, the incident points to several practical actions businesses can review now:

• Review GitHub account security by enforcing strong authentication, minimising standing access and checking for unused or excessive privileges.
• Audit repository and organisation access for employees, freelancers and former contractors.
• Inspect CI/CD secrets handling and avoid exposing sensitive credentials to public workflows unless absolutely necessary.
• Rotate sensitive tokens and keys if there is any indication of exposure or unnecessary repository-level access.
• Use least-privilege credentials so that any leaked token has limited operational impact.
• Monitor repositories and workflows for unusual commits, runner activity, secret access or configuration changes.
• Separate development, staging and production credentials to reduce the blast radius of a compromise.
• Clarify incident response ownership between internal teams and external development suppliers.

For business leaders, the wider lesson is that source code platforms are part of critical digital infrastructure. They should be governed with the same attention given to cloud admin accounts, production systems and customer data environments.

If further technical findings or vendor statements emerge, companies using GitHub should compare them against their own repository security posture and third-party development processes.