node-ipc Compromised: A Dormant Maintainer, an Expired Domain, and What We Think Happened

On May 14, 2026, [email protected] was published to npm with an obfuscated infostealer appended to its CommonJS bundle. The technical write-up of the payload itself was nailed by the community in real time on Issue #15 of the node-ipc repository, and the most complete reverse engineering ships from @nullcharb. We are not going to re-do that work here.

What we want to talk about is the maintainer identity that pushed those versions, and why we think the most likely root cause is an Email Takeover. We do not have ground truth, only the registry, the DNS records, and the publish history, but the pattern is consistent enough that Depi flagged the maintainer 15 days before the publish, and we notified affected clients ahead of the registry hitting 12.0.1.

The Maintainer Behind the Publish

node-ipc has twelve npm maintainers. The three malicious versions did not come from the project's lead, RIAEvangelist. They came from a long-dormant secondary maintainer, atiertant, whose npm contact email is [email protected]. The domain is tied to a software company that, as far as we can tell from public records, no longer exists.

That is the part of the story we want to sit with. The package itself was not the weak link. The version-control history was not the weak link. The trust anchor that quietly degraded over years was a maintainer identity that had stopped being actively held by anyone.

A Four-Year Dormant Account

The atiertant identity last legitimately published anything on 2022-04-29 (@synapps/[email protected]). Between that publish and May 14, 2026, the account was silent for 1,476 days while retaining publish rights on node-ipc, despite having never personally pushed a node-ipc version. The three releases on May 14 are the first and only times this identity has ever touched that package.

This is the risk profile we want to focus on:

• A high-blast-radius package, well into the long tail of "everyone depends on it but nobody is actively reading the maintainer roster."
• A co-maintainer who has been silent for years but never had their publish rights revoked.
• A contact identity anchored to the DNS of a company that no longer exists.

Each of those on its own is benign. The combination is what we believe an attacker exploited, and the combination is what we think is worth watching.

What We Think Happened: Likely Email Takeover

We want to be careful here. We did not observe the password reset. We did not see the attacker's mailbox. What we have is the public surface of the maintainer's contact identity, and what it shows is consistent with Email Takeover via an expired domain. It is a class of compromise that is not new, that Matthew Bryant wrote up in 2022 against Angular, and that we documented a similar version of in Hacking Millions of Companies Around the World with 10$.

On 2026-03-10, atlantis-software.net was re-registered. The new registration sits on Namecheap, with A record 192.64.119.168 in Namecheap's parking range and MX records pointing to Namecheap PrivateEmail (mx1.privateemail.com, mx2.privateemail.com). Mail reception was actively configured. Two months and four days later, the three malicious versions appeared on npm, published by the identity whose registered contact email lives on that domain.

We cannot prove from outside the registry that the attacker actually used a password reset email. What we can say is that the publishing identity had a contact email at a domain that had been allowed to lapse, the domain was re-registered with mail actively configured, and 65 days later that same identity pushed code for the first time in four years. Our working hypothesis is Email Takeover. If the registry has logs that point somewhere else (a stolen session, a compromised endpoint on the legitimate maintainer's machine, a different identity path entirely), we would want to know.

What the Publish History Shows

Every npm tarball carries the identity of who pushed it. The three versions published on May 14 share an author that has never released node-ipc before:

Different identity, significantly newer toolchain than the project's lead has historically used, 55-second window, and the publishes span three different major version lines (9.x, 9.x, and 12.x) so that anyone on latest or on ^9, ^10, ^11, or ^12 ranges auto-resolves to a poisoned version.

There is also no corresponding source in the GitHub repo. RIAEvangelist/node-ipc has only two git tags (10.1.0 and 12.0.0), and the default branch's last commit is from August 2024. The malicious tarballs were uploaded directly via npm publish and the git history was not touched.

The Payload, In One Paragraph

The malicious code lives only in node-ipc.cjs and is appended as an obfuscated self-executing function after the legitimate module.exports. It harvests environment variables, SSH keys, cloud credentials (~/.aws, ~/.config/gcloud, ~/.azure), shell history, browser profile data, and .git configs; packs them into a manually-constructed tar archive; encrypts with XOR-over-HMAC-SHA256; chunks the result into DNS subdomain labels; and exfiltrates over dns.Resolver pointed directly at 8.8.8.8 and 1.1.1.1 to bypass corporate DNS filtering. It runs as a detached child, guards against re-execution with __ntw / __ntRun, and only activates when sha256(path.basename(require.main.filename)) matches a hardcoded hash. The full reverse-engineering, including the deobfuscated source, lives on Issue #15 of the node-ipc repository.

We are intentionally not re-doing that analysis here. It is excellent work, it is already public, and the point of this article is not the cleverness of the payload. The point is everything that happened before the payload was uploaded.

What Depi Saw 15 Days Before the Publish

To be precise about what Depi did and did not do: Depi did not detect the published backdoor. Depi flagged the maintainer identity as exposed to Email Takeover. The community caught the published payload, and credit for that belongs to the researchers listed below.

At Wed, Apr 29, 2026 at 14:43:41 CEST, Depi autonomously flagged the atiertant maintainer identity on node-ipc. The lapsed atlantis-software.net contact domain was the trigger. The finding shipped as a High severity issue with a risk score of 80, fifteen days before any malicious version was published.

Every Depi-monitored project depending on node-ipc received the finding alongside a pinning recommendation: pin away from versions that could be published by atiertant, or rip the dependency out entirely, until the maintainer's identity chain is independently verified.

We are not claiming this kind of finding catches every supply chain attack. It does not. It catches the subset where the trust anchor on a maintainer identity quietly degrades before the publish. Email Takeover via expired domain is one shape of that. Other shapes (dormant accounts, inconsistent publishing history, credential leakage on adjacent services) share the same property: the package on the registry looks fine, but the identity behind it has been silently up for grabs for a while.

The Compromise Itself Was Caught by the Community

Credit for catching the actual published backdoor belongs to a handful of independent researchers working in real time on Issue #15:

• @nullcharb filed the issue with a full reverse-engineering of the obfuscated payload. The technical decomposition referenced earlier is built on top of that work.
• @carlini confirmed the payload, reported it to npm Security inside the first hour, and pinpointed the C2 at sh.azurestaticprovider.net.
• @jimmytsadiotis flagged that 9.1.6 was also affected, expanding the publish window from two versions to three.
• @cyb3rjerry posted a reconstructed, deobfuscated version of the malicious code.
• @ashishkurmi flagged the compromise from StepSecurity and published a parallel write-up.

Structural risk modeling and post-publish payload forensics are different jobs, and you need both. Depi alerted its clients ahead of the publish. The broader ecosystem learned what 12.0.1 actually contained because of the people above. Neither side substitutes for the other.

Indicators of Compromise

Package

• [email protected], 9.2.3, 9.1.6 on npm
• 12.0.1 shasum: fe5d107b9d285327af579259a32977c4f475fa26
• Malicious code present only in node-ipc.cjs

Runtime artifacts

• Temp files uname.txt or envs.txt in os.tmpdir() or os.homedir()
• A directory at path.join(os.homedir(), 'nt-<hash>')
• __ntw or __ntRun in the process environment
• Detached Node.js child processes with stdio: 'ignore'

Network

• Long DNS subdomain labels issued by Node.js processes
• Direct queries to 8.8.8.8 or 1.1.1.1 bypassing the local resolver

Quick check

npm pack [email protected] --pack-destination .
tar -xzf node-ipc-12.0.1.tgz
tail -c 5000 package/node-ipc.cjs

If the tail contains a hex-name-heavy IIFE after the module.exports, the payload is present.

Timeline

• Mar 10, 2026: atlantis-software.net re-registered on Namecheap; PrivateEmail MX records configured
• Apr 29, 2026 at 14:43:41 CEST: Depi flags Email Takeover on the atiertant identity (15 days lead time)
• Apr 29 - May 14, 2026: Depi clients alerted; pinning guidance issued
• May 14, 2026, 14:25–14:26 UTC: [email protected], 9.2.3, and 9.1.6 published by atiertant
• May 14, 2026: Public disclosure on the node-ipc repository

What to Do If You Installed 12.0.1

Treat the host as compromised:

1. Rotate every secret, API key, and token readable from the process environment.
2. Rotate SSH keys present in ~/.ssh.
3. Review cloud audit logs for anomalous activity on any credential reachable from the affected machine.
4. Inspect DNS query logs for long-subdomain queries to 8.8.8.8 or 1.1.1.1 originating from Node.js processes.
5. Look for nt-* directories under home directories and uname.txt / envs.txt in temp paths.
6. Pin node-ipc away from 12.0.1 or remove the dependency until the account control chain is independently verified.

What This Means

The interesting story here, to us, is not the payload. It is a dormant maintainer identity sitting on node-ipc for four years, anchored to the DNS of a company that no longer exists. We think Email Takeover is the most likely root cause, but we want to be honest that we are inferring it from the public surface: the contact email on the npm record, the WHOIS history of the domain, the MX configuration on the new registration, and the publish timing. Better evidence may surface; if it does, the story changes.

What we are more confident in is the maintainer-side observation: the identity that published the malicious versions had been visibly degraded for a long time, and that degradation was observable before anything was published. Standard supply chain tooling looks at the package. We think there is real value in also continuously looking at the people who can push to it. That is what Depi is built around, and it is what bought our clients 15 days here.

The community caught the payload. We want to be clear about that. The researchers listed above deserve every bit of credit. Our hope is just that next time the maintainer identity itself is something more defenders are watching, so the publish does not need to be caught at all.