An attacker spent two days using stolen credentials for 4,837 GitHub accounts to push a secret stealer into repositories those accounts could write to, according to Aikido Security.
SafeDep, tracking the same event, counted 8,093 public repositories that received malicious commits between Tuesday afternoon and early Thursday. Both firms warn the true figure is higher because they could only see public default branches.
The probe before the payload
Each attempt opened with a pull request titled docs dependency audit notes, raised from a branch named wfx-docs. The purpose was reconnaissance: if the pull request landed, the account had write access.
Those test pull requests hit 61,764 repositories. Roughly 10,400 came through collaborator or organisation access rather than personal ownership, and 92 percent of those were still open when the company checked.
The stealer ran in at least 1,806 repositories. In 7,309 it was added to an existing workflow; in 771 it arrived as an npm postinstall hook, which also fires on a developer’s own machine.
What gets lifted and how to respond
It reads Actions secrets and variables, the workflow GITHUB_TOKEN, OIDC and runtime tokens, AI service keys, and credential files for AWS, Azure, GCP, Kubernetes, npm, PyPI and SSH. On self-hosted runners it also pulls instance metadata credentials. It ships data by HTTP POST or over Telegram.
Aikido’s rule is blunt: any account that opened one of those test pull requests is compromised, whether or not the stealer fired. Owners should revoke the author’s tokens, OAuth grants, SSH keys and sessions, then rotate every secret the repository can read.
Detection starts with the branch name, that pull request title, and commits labelled ci refresh build cache. The hashes and exfiltration addresses are published in both write-ups.
