Three node-ipc Versions Hide a Stealer Backdoor — and the Attacker Took Over a Dead Maintainer's Domain to Publish Them
Three published versions of node-ipc — a package with 822,000 weekly downloads — hide an obfuscated stealer backdoor that exfiltrates 90 categories of developer and cloud secrets over DNS. The attacker hijacked a lapsed maintainer domain to publish them.
A package that thousands of build pipelines pull in without thinking — node-ipc, 822,000 downloads a week — just shipped three versions with an obfuscated stealer wired into the code itself. It fires the moment the package is loaded, sweeps the host for 90 categories of secrets, and smuggles them out through DNS. The way the attacker got publish access is its own warning.
PORTLAND, OR — Researchers at Socket and StepSecurity disclosed on May 14, 2026 that three published versions of the npm package node-ipc — node-ipc@9.1.6, node-ipc@9.2.3, and node-ipc@12.0.1, all published the same day — contain obfuscated stealer and backdoor behavior. node-ipc is a Node.js inter-process-communication library that sees roughly 822,000 downloads a week and sits as a transitive dependency under a long list of widely used development tools. Per Socket's analysis, the malware fingerprints the host environment, enumerates and reads local files, compresses and chunks the collected data, wraps the payload in a cryptographic envelope, and exfiltrates it through a network endpoint chosen via DNS and address logic. StepSecurity reports the heavily obfuscated payload fires when the package is required at runtime and attempts to exfiltrate a broad set of developer and cloud secrets — 90 distinct categories — to an external command-and-control server.
Two technical details make this more dangerous than a typical typosquat. First, the malware does not rely on npm lifecycle hooks — the usual preinstall and postinstall scripts that security tooling watches. It is appended directly to node-ipc.cjs as an immediately-invoked function expression, so it executes unconditionally every time any code calls require('node-ipc'). Second, the exfiltration channel is DNS: the payload overrides local DNS resolvers with public services and sends stolen data out through DNS TXT-record queries, a channel that most egress filtering does not inspect. The attack vector is the part defenders should sit with. Security researcher Ian Ahl traced it to a dormant maintainer account takeover via domain takeover — a domain tied to the maintainer account had lapsed on January 10, 2025, and was re-registered through NameCheap on May 7, 2026, one week before the malicious versions shipped. This is not the 2022 node-ipc incident, when the maintainer themselves sabotaged the package; this is a separate, financially motivated actor who bought their way into an abandoned credential.
'Required at Runtime' Is the Detail That Should Worry You
Most npm supply chain malware announces itself, at least to tooling: it hangs its payload off a lifecycle hook — preinstall, install, postinstall — because that is the simplest way to guarantee execution. Security scanners watch those hooks closely. The node-ipc payload does not use them. It is appended to node-ipc.cjs as an immediately-invoked function expression, which means it runs the instant anything in your codebase, or anything in your dependency tree, calls require('node-ipc'). There is no install-time signal to catch. The trigger is the ordinary, expected act of using the library. For a package that is overwhelmingly a transitive dependency — pulled in not because a developer chose it but because something else did — that is close to a worst-case execution model.
The exfiltration channel compounds the problem. The payload wraps the stolen data in a cryptographic envelope and sends it out over DNS — overriding the host's DNS resolvers with public services and tunneling data through TXT-record queries. DNS is the channel almost every network lets through, and almost no egress filter inspects at the payload level. An organization that monitors HTTP egress, blocks unknown outbound TLS, and still treats DNS as plumbing has a blind spot exactly where this malware operates. The combination — runtime trigger, no lifecycle hook, DNS exfiltration — is a deliberately quiet design, and it is becoming a generational pattern in npm stealers, not a one-off.
The Attacker Bought a Dead Domain to Inherit a Live Publish Token
The most important sentence in this disclosure is about how the attacker got in. Researcher Ian Ahl traced the compromise to a dormant maintainer account takeover via domain takeover: a domain associated with the node-ipc maintainer account had lapsed on January 10, 2025, sat unregistered for over a year, and was re-registered through NameCheap on May 7, 2026 — seven days before the malicious versions were published. Owning the domain meant controlling the email address tied to the maintainer account, and controlling that email meant the ability to reset credentials and publish. The attacker did not exploit a vulnerability in npm or in node-ipc. They bought an abandoned identity for the price of a domain registration.
That vector is not specific to node-ipc, and that is what makes it strategic. Every package registry — npm, PyPI, RubyGems, crates.io — is full of packages whose original maintainers have moved on, whose contact domains have lapsed, and whose publish credentials are still live. This is the same registry-trust erosion The CyberSignal documented when RubyGems suspended new signups after a flood of malicious packages, and it sits alongside the broader pattern of TeamPCP's repeated supply chain compromises and the Mini Shai-Hulud campaign. The node-ipc takeover is a reminder that the supply chain attack surface is not just the code in a package — it is the entire lifecycle of the credentials that can publish it, including the parts everyone has forgotten about.
Audit Your Lockfiles, Then Rotate Everything the Build Touched
The immediate action for any organization is mechanical and should happen today: search every package-lock.json and yarn.lock for node-ipc@9.1.6, node-ipc@9.2.3, and node-ipc@12.0.1, and check transitive dependencies, not just direct ones — node-ipc is far more often pulled in indirectly than chosen deliberately. If any compromised version was installed since May 14, treat it as a confirmed credential exposure event, not a maybe. The payload's stated purpose is to harvest 90 categories of developer and cloud secrets; assume anything reachable from the affected environment is burned. Rotate developer credentials, CI/CD secrets, GitHub and npm tokens, and cloud access keys for every environment where a malicious version ran.
The structural fixes are the ones that pay off past this incident. Pin dependencies to exact versions in lockfiles and treat transitive and optional dependencies with the same scrutiny as direct ones. Set npm config set ignore-scripts true in CI/CD environments — and recognize that node-ipc's runtime-trigger design means script-blocking alone would not have stopped it, which is the point: defense-in-depth, not a single control. Most importantly, start monitoring DNS egress from build infrastructure and developer machines for the pattern this malware uses — bulk TXT-record queries to unfamiliar domains, resolver overrides — because DNS exfiltration is now common enough in npm stealers that treating DNS as uninspected plumbing is a documented, exploited gap.
The CyberSignal Analysis
Signal 01 — DNS Exfiltration and Runtime Triggers Are the New npm Stealer Baseline — Defend Accordingly
The node-ipc payload is built to evade the controls most organizations actually have: it skips npm lifecycle hooks so install-time scanners see nothing, fires on require() so the trigger is normal usage, and exfiltrates over DNS TXT records so egress filtering misses it. SOC and threat-hunting teams should treat DNS as an inspected channel, not plumbing — hunt for resolver overrides, bulk TXT-record queries to unfamiliar domains, and unusual encrypted outbound traffic from Node.js processes on build runners and developer machines. Set npm config set ignore-scripts true in CI/CD as one layer, but do not mistake it for sufficient: the runtime-trigger design is specifically built to survive it. Add Socket and StepSecurity's published indicators of compromise to detection as they land.
Signal 02 — The Supply Chain Attack Surface Includes Every Lapsed Maintainer Domain
The node-ipc takeover did not exploit a software flaw — the attacker re-registered a maintainer's expired domain, inherited the associated email, and used it to gain publish access. That vector applies to a large fraction of every package registry, where original maintainers have moved on and contact domains have quietly lapsed while publish credentials stayed live. This is registry-trust erosion of the kind that forced RubyGems to suspend new signups, and it means dependency risk management has to extend past the code to the credential lifecycle. Pin exact versions, treat transitive and optional dependencies with full scrutiny, implement automated dependency monitoring with Socket, Snyk, or equivalent tooling, and assume — as a baseline 2026 threat-model assumption — that npm, PyPI, and RubyGems compromise is continuous, not episodic.
What to Do This Week
- Audit every package-lock.json and yarn.lock — including transitive dependencies — for node-ipc@9.1.6, node-ipc@9.2.3, and node-ipc@12.0.1. node-ipc is most often an indirect dependency, so a direct-dependency check is not enough.
- If any compromised version ran in your environment since May 14, 2026, treat it as a confirmed credential exposure: rotate developer credentials, CI/CD secrets, GitHub and npm tokens, and cloud access keys for every affected environment.
- Start inspecting DNS egress from build infrastructure and developer machines. Hunt for DNS resolver overrides and bulk TXT-record queries to unfamiliar domains — the malware's exfiltration channel — and add Socket and StepSecurity indicators of compromise as they are published.
- Set "npm config set ignore-scripts true" in CI/CD environments as one defense layer, and pin dependencies to exact versions in lockfiles. Treat transitive and optional dependencies with the same scrutiny as direct ones.
- Implement automated dependency monitoring with Socket, Snyk, or equivalent tooling, and update your threat model to treat continuous npm, PyPI, and RubyGems compromise — including via lapsed maintainer credentials — as a baseline assumption rather than an episodic event.
