An automated attack campaign is reportedly using stolen GitHub tokens to access repositories, add malicious GitHub Actions workflows, and expose stored secrets in workflow logs. According to an analysis by Wiz cited in the source report, the activity has affected private repositories and GitHub Enterprise environments.

For European businesses, the incident is relevant because GitHub often sits at the centre of software development, website deployment, automation and cloud infrastructure management. If secrets stored in repositories or CI/CD pipelines are exposed, the impact can extend beyond source code to production systems, cloud accounts, APIs and customer-facing services.

What happened

According to the source report, attackers are using stolen GitHub tokens to gain access to repositories. They then plant or modify workflows so that repository secrets are printed into GitHub Actions logs. The attackers reportedly download those logs and then delete the workflow runs to reduce visibility.

Wiz said the campaign is automated and has succeeded in private repositories as well as GitHub Enterprise environments. Based on the information provided, the attack does not depend on publicly exposing the repository itself. Instead, it abuses trusted automation inside the development environment.

The source also references a GitHub safeguard that pauses certain workflow runs. However, businesses should be careful not to assume that platform protections alone eliminate the risk, especially when valid tokens have already been compromised.

Why it matters for European businesses

This is not just a developer issue. Many SMEs, e-commerce firms, SaaS providers and digital agencies use GitHub to manage websites, applications, infrastructure code and deployment pipelines. Secrets stored in GitHub or injected into workflows can include:

• Cloud access keys
• API tokens for payment, CRM or marketing platforms
• Database credentials
• Deployment keys for hosting environments
• Internal service accounts

If those credentials are exposed, attackers may be able to move from the code repository into production systems, staging environments or third-party business platforms. That creates risks including service disruption, data exposure, website compromise, unauthorised infrastructure changes and follow-on supply chain attacks.

For companies operating in regulated sectors or handling customer data, a compromise involving development credentials can also trigger broader security and compliance consequences. The precise legal implications depend on what systems or personal data were affected, and should not be assumed from the initial report alone.

Who may be affected

The most exposed organisations are likely to be those that rely heavily on GitHub-based automation and store sensitive credentials in repository or organisation secrets. This can include:

• Software teams and SaaS businesses using GitHub Actions for build and deployment pipelines
• E-commerce companies managing storefront deployments, integrations and payment-related services
• Digital agencies maintaining multiple client repositories and deployment workflows
• Internal IT teams using infrastructure-as-code and automation scripts
• GitHub Enterprise users with large developer groups and broad token usage

Smaller businesses may be especially vulnerable if GitHub administration, CI/CD security and credential hygiene are handled informally or without dedicated security review.

What companies should consider

Businesses using GitHub should review their exposure across tokens, workflows and secrets management. Based on the reported attack pattern, practical steps may include:

• Audit GitHub tokens and revoke any that are unnecessary, old or insufficiently protected
• Review recent workflow changes, especially unexpected new workflows or edits to existing Actions files
• Check Actions logs and run history for suspicious activity, including unusual secret output or deleted runs
• Rotate sensitive credentials stored in GitHub secrets if compromise is suspected
• Reduce secret exposure by limiting which workflows and repositories can access which credentials
• Use stronger authentication controls around developer accounts and administrative access
• Separate production credentials from development pipelines where possible
• Improve monitoring for repository changes, token misuse and CI/CD anomalies

Companies should also review whether developers or service accounts hold broader GitHub permissions than required. In many cases, the business risk comes less from one compromised token and more from the amount of infrastructure that token can reach.

For European organisations, the broader lesson is that CI/CD platforms are part of critical digital infrastructure. Security reviews should cover not only servers and endpoints, but also repository permissions, build pipelines and automation logs.