A compromised GitHub account can become a route into cloud infrastructure—not just a source of unwanted commits. The Hacker News reports that an attacker used 4,837 hijacked accounts to deploy a CI secret stealer, with execution observed in at least 1,806 repositories. For engineering teams, the immediate concern is what those workflows could access and whether stolen credentials enabled persistent cloud access.

The November 12 report draws on investigations by Aikido Security and SafeDep. The response guidance below separates reported campaign findings from practical defensive steps. A clean-looking default branch is not enough to rule out exposure.

What the reported numbers actually mean

Aikido identified test pull requests in 61,764 repositories. These probes used the title docs: dependency audit notes and the branch wfx-docs to check write access. A probe does not, by itself, establish that the secret stealer executed. However, Aikido says an account that opened one of the attacker's test pull requests should be considered compromised even when the payload did not run.

SafeDep separately counted 8,093 repositories receiving malicious commits. That is a different measurement from confirmed execution: its search covered default branches of public repositories. Neither count should be treated as a complete inventory of potentially affected private repositories.

The report does not establish how the original account credentials were stolen. It also cautions against attributing this campaign to the same actor as October's GhostAction activity merely because compromised accounts overlap.

Why reverted commits do not mean recovery

The attacker reportedly added malicious code to existing workflows and, in some repositories, to an npm postinstall hook. Changes were often reverted within minutes. Workflow logs and runs were also deleted where the stealer executed.

This creates two distinct exposure paths: a CI runner executing an altered workflow, and a developer machine running npm install against an affected commit. Restoring the repository removes neither credentials already stolen nor cloud access created during execution.

The reported collection scope includes workflow secrets and variables, GitHub and OIDC tokens, credential files for cloud and package services, and repository data. On self-hosted runners, the payload can also collect instance metadata credentials and information about Docker containers and systemd units. Treat those runners as incident-response assets, not merely disposable build jobs.

Triage repositories and identities first

Start with activity from Tuesday, November 10, and expand the review if evidence points further back. Search organization and collaborator repositories, not just projects owned by the suspected account.

Useful reported indicators include:

- Pull requests titled docs: dependency audit notes and branches named wfx-docs.
- Short-lived branches matching chore/[a-z0-9]{8} or ci-check-[0-9]{4}.
- Commits named ci: refresh build cache, particularly large additions to existing workflows.
- chore: add ci helper commits introducing a .ci-xxxxxx.sh script and a package.json postinstall hook.
- New .github/workflows/build-audit-xxxxxx.yml files, followed by cleanup or restore commits.

Names alone are investigative leads, not proof that every matching commit is malicious. Correlate them with authorship, diffs, workflow history, and audit events. The researchers warn that missing loot artifacts or step summaries do not exclude theft; unexplained missing runs around suspicious commits deserve investigation.

Preserve available evidence, then suspend suspect automation and revoke affected account tokens, sessions, OAuth grants, and SSH keys. Enable or strengthen two-factor authentication, but do not mistake that for revocation of already stolen access.

Rotate secrets—and remove cloud persistence

Where the stealer ran, treat every secret and cloud role available to the workflow as compromised. Inventory reachable credentials before rotating them, including deployment, package publishing, infrastructure, and third-party service credentials. Review repository variables for sensitive values as well.

Credential rotation is not the finish line: cloud trust changes can outlive the stolen token.

The reported payload can create AWS access keys, alter AWS role trust policies, and add Azure federated identity credentials. Check for unauthorized changes rather than assuming new secrets restore security:

- AWS: Investigate AssumeRoleWithWebIdentity or AssumeRole sessions named wfx-*, especially subsequent CreateAccessKey and UpdateAssumeRolePolicy events.
- Microsoft Entra ID: Review application federated identity credentials named wfx-ci-* and remove unauthorized entries.
- Google Cloud: Examine GenerateAccessToken and SignJwt activity originating from GitHub workload identity pools.
- Vault: Review JWT logins using the GitHub OIDC issuer.

These are reported hunting leads, not an exhaustive detection rule. Compare trust policies and identity configuration with approved baselines. Isolate exposed developer machines and self-hosted runners, and restore them from trusted images where warranted before supplying replacement credentials.

Check publishing paths before restarting builds

The report identifies malicious version 3.14.3 of the Packagist package digitalelvis/neuronai-studio. It notes that a normal Composer installation does not execute the stealer, whereas running npm install inside the package's vendor directory does. Block the affected version and investigate exposure rather than assuming every installation followed the same execution path.

Review automated releases and package-publishing permissions across affected repositories. The report also describes contaminated Go-module workflows without changes to Go code or release binaries, illustrating why malicious repository content and executed malware are different findings.

Before resuming automation, require review of workflow changes, reduce token permissions, restrict cloud federation to intended repositories and environments, and gate sensitive deployment secrets. Record which accounts, workflows, machines, credentials, and cloud trust relationships were checked. Recovery is complete only when the unauthorized access paths—not just the visible commits—have been removed.

Source: The Hacker News report on the GitHub CI secret-stealing campaign.