A Large-Scale Campaign Against GitHub CI Pipelines

A coordinated credential-stuffing campaign against GitHub has exposed how much trust organizations place in their continuous integration (CI) workflows — and how quickly that trust can be turned against them. According to research published by security firm Aikido Security, an attacker leveraged stolen credentials for 4,837 GitHub accounts to inject a secret-stealing payload into repositories those accounts had write access to, with the malicious code confirmed to have executed in at least 1,806 repositories.

The campaign, which began on a Tuesday, represents one of the more aggressive attempts in recent memory to harvest the secrets that automated build and deployment pipelines can reach.

How the Attack Worked

The mechanics of the operation are deceptively simple, which is part of what makes it dangerous. Rather than exploiting a software vulnerability in GitHub itself, the attacker relied on valid-but-stolen account credentials. With write access to a repository, an intruder can modify workflow configuration files — the YAML definitions that tell GitHub Actions what to run, when, and with which permissions.

By committing changes to these workflow files, the attacker caused a malicious payload to execute inside the CI environment. The stealer was purpose-built to scoop up the secrets and cloud credentials that a repository's CI workflows are authorized to access. That is a significant escalation: CI runners frequently hold deployment keys, cloud provider tokens, package registry credentials, and signing certificates — material that can be far more valuable than the source code itself.

Because the payload ran in the context of legitimate pipelines, it would have blended in with normal build traffic, making detection harder for teams that don't closely monitor workflow file changes.

The Scale of Exposure

The numbers tell the story. Nearly 4,900 compromised accounts provided the attacker with a wide footprint of writable repositories, and the payload is reported to have run in over 1,800 of them. Aikido Security noted that the attacker has likely already collected secrets from a substantial portion of those repositories.

This is not the first time CI/CD pipelines have been targeted, but the breadth of account compromise here stands out. It underscores a persistent weakness in the software supply chain: the human and automated identities that hold write access to code repositories are often poorly protected, and the permissions granted to CI workflows are frequently broader than necessary.

Why CI Secrets Are a Prime Target

CI/CD systems sit at a privileged intersection. They pull code, build artifacts, and deploy to production — meaning their credentials often unlock the most sensitive parts of an organization's infrastructure. A secret stolen from a CI environment can enable:

  • Cloud account takeover, if long-lived cloud access keys are stored as repository secrets.
  • Supply chain compromise, if package publishing tokens are exposed, allowing an attacker to push malicious releases to downstream consumers.
  • Lateral movement, if deployment credentials grant access to production systems.

The attacker's focus on CI-reachable secrets suggests a deliberate strategy to convert repository access into broader infrastructure access.

Mitigation and Hardening Guidance

The incident reinforces several well-established but frequently neglected controls:

  1. Enforce strong authentication. Phishing-resistant MFA, particularly passkeys or hardware security keys, dramatically reduces the value of stolen passwords. Organizations should also audit for dormant or over-privileged accounts.
  2. Apply least privilege to CI workflows. Workflow tokens and secrets should be scoped to exactly what a job needs. GitHub's permission settings for GITHUB_TOKEN should default to read-only, with write permissions granted explicitly where required.
  3. Prefer short-lived credentials. OIDC-based federation to cloud providers eliminates long-lived static keys in repository secrets — a direct counter to credential-stealing payloads.
  4. Monitor workflow changes. Commits touching .github/workflows files deserve scrutiny. Branch protection rules, required reviews, and audit logging on workflow modifications can catch tampering early.
  5. Rotate exposed secrets. Any repository whose workflows were modified should treat all associated secrets as compromised and rotate them promptly.

The Bigger Picture

This campaign is a reminder that the software supply chain's weakest link is often identity. Attackers do not need a zero-day when thousands of valid credentials can be bought, guessed, or phished. For defenders, the lesson is to treat CI/CD systems as tier-zero infrastructure: monitor them, restrict them, and assume that any credential stored within them could one day be exfiltrated.

Organizations that rely on GitHub Actions should review their workflow permissions and secret storage practices immediately, and security teams should check audit logs for unexpected workflow modifications around the reported timeframe.

Source: The Hacker News