By ByteBot
On May 14, three malicious versions of node-ipc — a foundational npm package with over 10 million weekly downloads — appeared on the registry loaded with an 80 KB credential-stealing payload. The attacker needed no zero-day exploit, no vulnerability research, no sophisticated toolchain. They registered an expired email domain for roughly the cost of a lunch, walked through npm’s own account recovery workflow, and inherited publish rights to a package embedded in Vue CLI and hundreds of other projects. Two hours before detection, every CI/CD pipeline that ran npm install against a tainted version quietly surrendered its secrets via DNS.
The Attack Required Eight Dollars and a Web Browser
The compromised account — atiertant — had valid publish rights to node-ipc but hadn’t touched the package in years. Its recovery email was tied to atlantis-software.net, a domain that expired and became available. On May 7, an attacker registered it through Namecheap, configured email hosting, and then triggered npm’s standard password reset. No code was cracked. No GitHub Actions pipeline was abused. npm’s own account recovery workflow did the work.
This is what makes the node-ipc attack different from the TanStack compromise three days earlier, which required deep knowledge of GitHub Actions OIDC token extraction and cache poisoning across fork trust boundaries. The node-ipc attack required a domain registrar and patience. That gap in attack complexity — with similar downstream impact — is the uncomfortable message here: npm’s supply chain security assumes maintainer accounts stay controlled indefinitely. Many don’t.
What the Payload Stole
The malicious code injected into node-ipc.cjs fired unconditionally on every require('node-ipc') call, targeting over 90 credential categories. The list is thorough enough to be alarming: AWS tokens (via IMDSv2), Google Cloud and Azure service account keys, Kubernetes service account tokens, SSH keys, GitHub CLI tokens, npm publish tokens, HashiCorp Vault tokens, .env files, and shell history. Stolen data was compressed into gzipped tar archives and exfiltrated via DNS TXT queries — a technique chosen to bypass standard network monitoring tools that don’t inspect outbound DNS for data. StepSecurity’s full technical breakdown details how the payload evaded detection for two hours.
Are You Affected?
The compromised versions are 9.1.6, 9.2.3, and 12.0.1. Safe versions are 9.2.1 and 12.0.0. Check your exposure:
npm list node-ipc
grep -A 3 '"node-ipc"' package-lock.jsonEven though all three malicious versions have been pulled from the registry, your lockfile may still reference them. If you ran npm install during the two-hour window on May 14 — and your version matches one of the three — treat every secret present in that environment as compromised.
What to Do Right Now
If a tainted version ran in any CI/CD environment, the remediation is broad by necessity. CSO Online’s coverage and the Snyk advisory both confirm the scope:
- Rotate GitHub Actions secrets,
GITHUB_TOKEN, and any repository deploy keys - Rotate AWS IAM credentials and audit CloudTrail for unexpected role assumptions, new IAM users, and cross-account access
- Rotate GCP and Azure service account keys and review their activity logs
- Rotate Kubernetes service account tokens and SSH keys from the affected environment
- Rotate npm publish tokens and audit your packages for unauthorized version releases
- Pin node-ipc in your lockfile: 9.x users to 9.2.1, 12.x users to 12.0.0
- Rebuild lockfiles from a clean state after removing tainted entries
The Fourth Wave This Year
This incident is the fourth significant strike attributed to TeamPCP in 2026, a financially motivated group tracked as UNC6780 by Google’s Threat Intelligence Group. The same group hit Trivy in March, Bitwarden CLI in April, and TanStack on May 11. Across the full campaign, researchers estimate roughly 500,000 credentials stolen and 300+ GB of data exfiltrated. Each attack used a different entry vector — a pattern suggesting the group is deliberately cataloguing exploitable weaknesses across the ecosystem, not simply repeating what worked before.
The node-ipc attack is a useful forcing function for any team evaluating their npm security posture. The threat is no longer limited to sophisticated state-sponsored actors exploiting novel vulnerabilities. A dormant maintainer account and an expired domain are sufficient to compromise a package running inside millions of developer environments. Treat any npm package with a maintainer whose email domain you don’t control as a potential liability. That’s the threat model worth updating before the next wave lands. For ongoing tracking, Unit 42’s npm threat landscape tracker is being updated continuously.
