node‑ipc contained obfuscated backdoors

1/ Socket said on May 14 that three newly published `node-ipc` versions on npm — `9.1.6`, `9.2.3` and `12.0.1` — contained obfuscated stealer/backdoor behavior. The package is a long-running Node.js inter-process communication library, not a lookalike or typosquat. (socket.dev) 2/ The key detail is where the payload lived. Socket said the malicious code was appended to `node-ipc.cjs`, the CommonJS entrypoint, while the ESM wrapper `node-ipc.js` was clean. In practice, that means impact depended on how downstream code imported the package. (socket.dev) 3/ Socket said the malware could fingerprint the host, enumerate and read local files, compress and chunk what it collected, wrap it cryptographically, and attempt exfiltration through a network endpoint chosen through DNS or address logic. That is install-time or dependency-resolution risk turning into post-install execution risk inside developer environments. (socket.dev) 4/ This matters because npm packages are not just code libraries. npm’s own documentation says install lifecycle scripts run during package installation, and `npm ci` and `npm install` both honor that behavior unless `ignore-scripts` is set. npm also notes lifecycle-script output is hidden by default in modern CLI versions unless `foreground-scripts` is enabled. (docs.npmjs.com) 5/ Even “just use `--ignore-scripts`” is not a complete answer. GitHub said in a February 2026 npm update that Git dependencies can still enable arbitrary code execution during install through `.npmrc` git-path overrides, which is why npm added a new `--allow-git` control. That is a reminder that package installation is an execution surface, not a passive download step. (github.blog) 6/ Socket described this `node-ipc` event as a suspicious republishing or reintroduction of malicious code into a known package, rather than a typosquatting attack. That distinction matters operationally: teams that only screen for fake package names can still miss compromised legitimate dependencies already allowed in policy. (socket.dev) 7/ The package also carries history. Socket said earlier `node-ipc` versions `10.1.1` and `10.1.2` were tied to the 2022 geo-targeted destructive malware incident, and `11.0.0` and `11.1.0` included the `peacenotwar` dependency linked to unauthorized file-writing behavior. In the current case, Socket said it classified all seven reviewed versions as malicious and recommended blocking them. (socket.dev) 8/ Another technical detail: Socket said every file in the reviewed tarballs was timestamped Oct. 26, 1985, a forensic artifact that can help investigators identify suspect artifacts. That does not prove motive by itself, but it gives defenders something concrete to hunt for in package archives and build caches. (socket.dev) 9/ For defenders, the immediate checks are straightforward. Socket said developers should avoid installing the affected versions and audit recent installs of `node-ipc`, especially `9.1.6`, `9.2.3` and `12.0.1`. npm documents `npm audit`, but its own docs also note some issues require manual review and cannot be fixed automatically. (socket.dev) 10/ The broader procurement lesson is that dependencies behave like vendors with code-execution rights. GitHub’s npm provenance and trusted publishing features are meant to tie packages to source and build systems, but provenance does not replace code review of what actually shipped. A package can be popular, legitimate and still become an execution path into developer and supplier environments. (github.com) 11/ What to watch next: Socket said the `node-ipc` case is still developing and that its threat research team is continuing to analyze package contents, confirm scope and extract indicators of compromise. The company said its updated incident page for `node-ipc` will carry the latest package list and findings. (socket.dev)