Eleven minutes. That is how long version 0.5.144 of the tensorlake npm package was live on October 8 before Socket's scanners flagged it as malicious, and it was long enough for a worm to start hunting for npm tokens, GitHub tokens, cloud keys and AI coding tool configurations on any machine that installed it. The day before, GitGuardian had reported that GhostAction, a campaign it first exposed in September 2025, had planted a secret stealing GitHub Actions workflow in 772 public repositories spread across 373 user and organization accounts over the month from August 31 to September 30.
Both attacks run on the same fuel: credentials that were already stolen. Neither needed a vulnerability in npm or GitHub. GhostAction commits its workflow as the victim, with credentials GitGuardian believes were stolen, and the tensorlake release went out through a compromised publishing account carrying a payload built to republish itself through every other package that account can reach. Each machine the npm payload infects yields the tokens needed to infect the next, which is what turns a one off theft into a worm; GhostAction, for its part, keeps running on account credentials that GitGuardian says are traded and reused by several crews.
How the npm worm spreads
The poisoned release carries a preinstall hook that runs an obfuscated loader through the Bun runtime, downloading Bun if it is missing. Nobody has to use the SDK at all; wherever lifecycle scripts are allowed, installing it is enough. Socket found the payload collecting npm and GitHub tokens, AWS, HashiCorp Vault and Kubernetes credentials, SSH keys, wallet files, environment files and the configuration files of AI coding tools such as Cursor, Windsurf and Claude.
Spreading is built in. The worm enumerates the packages tied to the victim's publishing identity, generates Sigstore provenance and republishes infected versions. Socket says the structure matches the August compromises of keyv and cacheable, a pattern it calls ChainDrop or Shai-Hulud. Sonatype found that the loader quits when it sees common CI environment markers, which it reads as a possible sign that developer workstations were the main target while cautioning that the code alone does not prove it, and that as of October 8 nothing confirmed the harvested data had been exposed. A PowerShell monitor installed as a logon task watches the stolen GitHub token and runs attacker supplied code if the token is revoked, so Socket advises removing the monitor before rotating anything.
GhostAction never went away
GitGuardian's data shows the GitHub side of the problem is older and more persistent. The injected workflow carries a hardcoded list of the secrets referenced in a repository's legitimate workflows and posts their values in a single request to a bare IP address over plain HTTP. The 2026 wave came in bursts, 143 repositories on August 31, about 400 between September 2 and September 5, and 103 on September 15, and targeted 2,577 secrets, led by SSH keys and server deployment logins (446), Azure credentials (218), container registry logins (142), database credentials (112) and AWS keys (106). In 92 cases the attacker simply edited a workflow planted in an earlier wave and pointed it at the new server, which is why GitGuardian calls it a campaign that never stopped.
GitHub's own controls blunted the September wave: of 3,669 workflow runs GitGuardian collected from 605 repositories, just 499 ran, because the platform held most of them for approval, and the completed runs leaked 26 secrets from 13 repositories. The October 8 burst was different. Socket watched two compromised maintainer accounts push a workflow posing as a security audit into 346 repositories within minutes, including an 18,420 star project published to both the Python and Rust package registries and an Uber owned repository. This variant also combs the full git history for AWS keys and for AI service, source control and SaaS tokens. Those runs executed, and Socket confirmed data left. By October 9 it counted more than 500 compromised accounts that had committed the file across tens of thousands of repositories.
What maintainers and companies can do
- Publish without long lived tokens. npm's trusted publishing, generally available since July 2025, lets a CI workflow authenticate with short lived OpenID Connect credentials tied to one repository and workflow. GitHub pushed every project toward it after the first Shai-Hulud worm in September 2025, when it also announced the revocation of classic tokens and a cap on granular publishing tokens of a seven day default and a 90 day maximum.
- Protect the accounts behind the tokens with WebAuthn or passkey based two factor authentication rather than one time codes, which npm has stopped offering for new setups, and treat a compromised account as fully compromised: revoke every session, token, OAuth grant and SSH key, not just the secrets a workflow named.
- Slow the install path down. Lockfiles pin exact versions, a cooldown of a day or two before adopting a brand new release gives scanners time to catch poisoned versions, and disabling lifecycle scripts during installation would have stopped the tensorlake payload from ever running.
- Hunt for secrets where the worms do. Secret scanning with push protection, approval requirements for workflow runs, and a search of the full git history including stale branches and tags mirror the techniques both campaigns use, and GitGuardian notes that stolen credentials are traded on, so one account can be hit by several unrelated crews.
The cleanup record is the sobering part. GitGuardian found that only 124 of the 772 repositories hit between August 31 and September 30, 16 percent, had been visibly cleaned by October 5, and Socket saw the October workflow still in place on the main branch of the repositories it checked a day after the burst. The tokens those files reach for are the same ones that would let the next worm publish itself.
