Thousands of Hijacked GitHub Accounts, One Fake ‘Audit Notes’ Pull Request: A Timeline of This Week’s CI Secret-Stealing Wave
Starting Tuesday, an attacker used stolen logins for 4,837 GitHub accounts to slip a credential stealer into build pipelines, and it ran in at least 1,806 repositories. Here is how the week unfolded, how to tell if a repository was hit, and what to rotate.
If your company writes software, pays a developer, or relies on an outside firm whose code lives on GitHub, this week brought a reminder that the automated build pipeline is now one of the most valuable places for an attacker to stand. Here is how the latest wave unfolded, step by step.
This timeline is built from The Hacker News report on the hijacked-account campaign, which draws on analyses by Aikido Security and SafeDep.
How the week unfolded
October: an earlier wave sets the stage
In a campaign known as GhostAction, stolen GitHub accounts were used to push secret-stealing workflows into repositories. Aikido found that accounts hit then were roughly 1,000 times more likely than other active accounts to show up again this week, and in more than 100 repositories the new stealer was added on top of October’s leftover workflow. Aikido stopped short of saying it is the same attacker, because the tools, infrastructure and methods differ.
Tuesday, November 10: the probing starts
Using credentials for 4,837 GitHub accounts, the attacker began opening pull requests titled “docs: dependency audit notes” from a branch named wfx-docs. These were tests to see whether each account could write to a repository. They landed in 61,764 repositories, and they did not stop at the accounts’ own projects: 10,431 were submitted through collaborator or organization access. SafeDep counts the first malicious commits from 12:46 UTC that day.
Tuesday through Wednesday: the stealer follows
Where the test succeeded, the attacker pushed a credential stealer. SafeDep counted 8,093 public repositories that received malicious commits on their default branches, mostly by inserting the stealer into an existing workflow and in 771 cases as an npm postinstall hook that also fires on a developer’s own machine. Aikido says the stealer actually ran in at least 1,806 repositories. The attacker usually reverted the change quickly and deleted the run logs, so a tidy-looking history is not proof of safety.
Wednesday, November 11: packages are touched
Through automated publishing triggers, the stealer reached at least one PHP package and one Go module. Version 3.14.3 of the Packagist package digitalelvis/neuronai-studio, published on Wednesday, is flagged as malicious; researchers advise blocking it and pinning 3.14.2 or earlier. Two versions of the Go module onuragtas/docker-env and one pseudo-version of vkuznet/gocurl also carry the stealer in workflow files, and 28 WebdriverIO repositories were hit through a bot account.
Thursday, November 12: still going
SafeDep’s count runs to 04:36 UTC. The Hacker News then found more pull requests with the same title opened between 05:04 and 05:38 UTC, from the same style of branch. Whether the stealer followed those is not yet known.
What the stealer goes after
- Every secret and variable the build workflow can read, plus the workflow’s own GitHub token and identity tokens.
- Credential files for AWS, Azure, Google Cloud, Kubernetes, npm, PyPI, SSH and other tools, and keys for AI services.
- On self-hosted build machines, cloud credentials from instance metadata and Docker and service configuration.
- Footholds that survive a password reset: it can open an AWS role’s trust policy to any account and add federated credentials prefixed wfx-ci- to Azure (Entra ID) applications.
Signs a repository was hit
- Branches named wfx-docs, ci-check- followed by four digits, or short-lived chore/ branches.
- Commits such as “ci: refresh build cache”, “chore: add ci helper”, “ci: restore” or “ci: cleanup”.
- A missing run number on the attacker’s commit, which researchers call the more reliable sign the stealer ran.
- In the cloud: Entra ID federated credentials named wfx-ci-* you did not create, or AWS role sessions named wfx-* followed by new access keys or trust-policy changes.
What this means for your company
Any account that opened one of the test pull requests should be treated as compromised, even if nothing else happened, and any repository where the stealer ran has effectively leaked every secret its build could see. The cleanup is unglamorous: revoke the affected user’s tokens, app grants, SSH keys and sessions, require two-factor sign-in, rotate every secret the repository can read, and hunt for the cloud backdoors listed above. Longer term, give build pipelines only the permissions they need, prefer short-lived credentials, and require review before workflow files change. If an outside developer manages your code, ask them directly whether they have checked.
Not sure what secrets your build pipelines or developers’ accounts could expose? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
