Skip to content
Security & Trust

Stolen GitHub logins let attackers plant a secret stealer in CI pipelines

Aikido ties 4,837 hijacked accounts to test pull requests in 61,764 repositories. It says the payload ran in at least 1,806.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Stolen GitHub logins let attackers plant a secret stealer in CI pipelines
In brief
  • Aikido says stolen GitHub credentials were used from November 10 to push a secret-stealing payload into repositories. It reports the payload ran in at least 1,806.
  • The payload targets CI secrets and cloud credentials, and Aikido says it deletes the run logs. A clean-looking history does not show a repository was spared.
  • Check for the probe pull request and for attacker commits with a missing run number. If the payload ran, treat every secret available to the workflows as compromised.

One stolen login opens many repositories

Software teams guard their production systems closely. The build pipeline that feeds those systems often gets less attention. Yet it holds keys to cloud accounts and package registries.

Security firm Aikido has described a campaign aimed at that pipeline. The lesson here is that one stolen developer login reaches every repository the developer can write to. That includes repositories owned by other organisations. The attacker does not have to break into a company. It borrows a person.

What Aikido found

Aikido says the campaign started on November 10 with stolen GitHub credentials. It tied 61,764 repositories to test pull requests from 4,837 hijacked accounts.

In 10,431 of those cases, the account did not own the repository. It had access as a collaborator or through an organisation.

Aikido says 92% of those 10,431 pull requests are still open. It takes that as a sign most owners of those repositories have not noticed.

The test is a pull request titled "docs: dependency audit notes", sent from a branch called wfx-docs. Aikido says it simply proves the attacker can write to the repository. Commits that carry the real payload come next.

Aikido sees signs that the payload actually ran in at least 1,806 repositories. It warns the true number may be higher. In most other repositories, nothing followed the test, or the workflow did not run. Aikido points to configuration and the hijacked user's permissions as the reasons.

How the payload works

Aikido describes three ways of delivering the payload. The first slips a large script into a workflow the repository already uses. The second adds a helper script and a postinstall hook to package.json. That hook runs whenever someone runs npm install. The third creates a short-lived branch holding a new workflow file.

All three carry the same shell script, about 1,500 lines long. Aikido splits its behaviour into four steps. It gathers credentials, widens access, sets up ways to stay, and sends the haul out.

The gathering step is broad. The script collects Actions secrets, the workflow token, and credential files for AWS, Azure, GCP, Docker and Kubernetes. It also takes keys for AI providers such as OpenAI and Anthropic, and shell histories. It even reads the memory of the runner's own processes to find tokens.

Next it widens access. It trades GitHub identity tokens for cloud sessions. On AWS, it calls iam:CreateAccessKey to mint long-lived keys for IAM users.

It also posts fake "success" checks early in the run. Aikido explains that branch protection looks at a check's name, not at which app sent it. So the fake checks satisfy the merge rules.

Then the attacker cleans up. Aikido says the commit is reversed and the run is deleted with its logs, all within about a minute. In this campaign the data left by HTTP POST to two servers, 194.150.166[.]244 and 18.143.168[.]96. Aikido adds that some exfiltration features were switched off.

Why rotating credentials may not be enough

Aikido lists steps built to outlast a credential reset. On Azure, the payload adds federated identity credentials to Azure AD applications. These are trust entries, and their names start with wfx-ci-. They tell Azure to trust the compromised repository.

Aikido says any workflow in that repository can then sign in to Azure with no stored secret. Rotating every token does not close that door.

On AWS, the payload rewrites the trust policy of a role so that any AWS account can use it. Both changes live in the cloud account, not in GitHub. Rotating GitHub secrets alone will not remove them.

Detection is tricky too. Aikido says the deleted run leaves a gap. An attacker commit with no matching run number is a better sign than hunting for stolen-data files. It adds that finding none of those files does not prove nothing was taken.

Who is behind it

Aikido measured the overlap with GhostAction, an October wave. Accounts hit then turned up again in November at a rate about a thousand times higher than other active accounts. In more than 100 repositories, the new payload was added to files the October attackers had already changed.

Aikido does not link the two waves to one actor. It sees different infrastructure, tooling and methods. It adds that stolen credentials often pass to several groups. The point for a buyer is simple. An account exposed once can be used again by someone else.

What to ask your team

Aikido says the payload also reached published packages through automated publishing triggers. It names a Packagist package, digitalelvis/neuronai-studio version 3.14.3. It also names two tags of the Go module github.com/onuragtas/docker-env. For the Go module, the payload sits only in a workflow file, so users of the module may not be affected.

Put these questions to your security lead this week.

Has anyone with write access to our repositories seen a pull request titled "docs: dependency audit notes" since November 10? Do any commits on short-lived chore/ branches, or titled "ci: refresh build cache", lack a matching workflow run? Which cloud roles and Azure applications can our workflows reach? Have we checked them for new federated credentials and open trust policies?

Aikido's advice is plain. If the payload ran, treat every secret and cloud role those workflows could reach as compromised. A pipeline is only as trusted as the people who can write to it. Each of those logins is now part of your attack surface.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Aikido Security.