4,837 GitHub Accounts, One Pull Request: The CI Secret Stealer

Starting Tuesday, an attacker used stolen credentials for 4,837 GitHub accounts to plant a secret stealer in repositories those accounts could write to. Aikido Security counted at least 1,806 repositories where the stealer ran. SafeDep, analysing independently, counted 8,093 repositories that received malicious commits in a sixteen-hour window — default branches of public repositories only, so the real number is higher.

The method was monotonous and effective. Each attack began with a pull request titled docs: dependency audit notes, opened from a branch named wfx-docs, purely to test whether the account could write to the repository. Those test pull requests appeared in 61,764 repositories.

Nine minutes of access is enough

In 7,309 repositories the stealer was appended to an existing workflow. In 771 it arrived as an npm postinstall hook — which also executes on a developer's laptop during npm install. The attacker usually reverted the commit within minutes and deleted the run logs, which is why the absence of a run number on the malicious commit is a better indicator than any artefact left behind.

What it took, and what it left behind

The stealer collected GitHub Actions secrets and variables, the workflow's GITHUB_TOKEN, OIDC and Actions runtime tokens, keys for AI services, and credential files for AWS, Azure, GCP, Kubernetes, npm, PyPI and SSH. On self-hosted runners it also read cloud credentials from instance metadata, Docker state and systemd units.

Some of it was built to outlive a rotation: it can rewrite an AWS role's trust policy to open the role to any AWS account, and add federated identity credentials prefixed wfx-ci- to Azure AD applications, so a compromised repo can sign in to Azure without any stored secret. That is why the response is not "rotate the token" but "assume the whole workflow was attacker-controlled".

Bone-headed, and entirely preventable

Nothing here was a zero-day. It was write access plus a workflow runner, the two things every repository already has.

Aikido's advice is unambiguous: any account that opened one of the test pull requests is compromised even if the stealer never ran, so revoke its tokens, OAuth grants, SSH keys and sessions, enable 2FA, and rotate every secret and variable the repository can read. Anyone who ran npm install on an affected commit should treat that machine as compromised.

ABN Asia builds software for organisations that cannot afford to be the case study. That means workflow files reviewed like production code, secrets scoped to the job that needs them instead of the whole repository, OIDC short-lived credentials instead of long-lived cloud keys, pinning and review on every dependency, and detection with a name attached to the alert.

You not only get software — you get secure software. If your CI holds credentials to anything that matters, talk to us: [email protected].

Source: The Hacker News, 12 November 2026, reporting analyses by Aikido Security and SafeDep.