A structured, evidence-based report of the node-ipc supply chain incident.

Executive Summary

In May 2026, three malicious node-ipc releases—9.1.6, 9.2.3, and 12.0.1—appeared on npm while the upstream project still showed 12.0.0, published through the official distribution channel. The root cause was unauthorized use of valid npm publishing authority tied to a dormant maintainer identity whose email domain (atlantis-software.net) had lapsed and been re-registered. The incident was detected through public GitHub issue #15 and contained within two days. This report reconstructs the technical behavior, the attribution evidence, the root cause, and the detection and remediation path; every claim carries a confidence rating (definitions in Appendix B).

Contents

1. Background: node-ipc overview and the source-vs-distribution gap
2. Incident Overview: Timeline and record of the three malicious releases
3. Impact Assessment: How trust propagates and why developer environments are targeted
4. Technical Analysis: Malware behavior from entry point through C2 infrastructure
5. Attribution & Evidence: Maintainer identity, domain evidence, and publishing path
6. Root Cause Analysis: Dormant identity tied to lapsed domain enabled the attack
7. Detection & Indicators: Package, runtime, and network indicators with detection priorities
8. Remediation & Recommendations: Corrective actions and trust-path hardening recommendations
9. Lessons Learned: Supply-chain trust properties and findings at a glance

Appendices

• Appendix A — Known Unknowns
• Appendix B — Scope, Evidence Method & Register
• Appendix C — About the Authors

Key Facts

About this report

This is a structured, evidence-based incident report. Claims carry confidence ratings (Confirmed / Supported / Plausible / Not established); see Appendix B (Scope, Evidence Method & Register) for the evidence register and method.

Related Coverage

Independent analyses of this incident:

• Datadog Security Labs — malware analysis and payload breakdown
• Socket.dev — package compromise detection and timeline
• StepSecurity — supply-chain attack writeup

1. Background

1.1 What is node-ipc?

A Node.js inter-process communication library

node-ipc is an open-source JavaScript library for inter-process communication (IPC). It lets separate Node.js processes exchange messages and coordinate, a common need for multi-process applications, CLI tooling, and local services. The public project lives at RIAEvangelist/node-ipc.

Why it is widely deployed

node-ipc is one of the most widely adopted packages in the Node.js ecosystem. It has accumulated over 2 billion downloads on npm, with a monthly download volume in the millions.

That ubiquity is precisely what made the incident consequential. Because the package is ordinary and trusted, a large number of developer workstations and CI environments install and run it without second thought. When a malicious version appears through the official npm channel, those same environments are the ones that may resolve and load the compromised code, which is the core of the source vs. distribution gap described in this report.

1.2 The source-vs-distribution gap

In May 2026, three malicious node-ipc releases appeared on npm while the upstream project still showed 12.0.0. The gap exposed how much modern software depends on trust outside the code we can see.

On 2026-05-14, the upstream node-ipc repository on GitHub still pointed to version 12.0.0 and appeared much as it had before. The software arriving through npm, however, no longer matched what the source page showed.

That day, three malicious versions of node-ipc—9.1.6, 9.2.3, and 12.0.1—appeared through the official npm distribution channel. The difference was confined to a version number, but it reflected a significant gap between the code developers inspect and the package they install: the two are not necessarily governed by the same systems, credentials, or trust relationships.

For most developers, the distinction is almost invisible. GitHub is where a project is read, discussed, and reviewed; npm is where the package is retrieved. In ordinary use, they feel like two windows onto the same thing. The node-ipc incident made clear that they are not. A source repository can remain unchanged while the distribution path around it changes completely.

That was what made the incident larger than a single case of malicious code. The package name remained familiar, the installation command remained familiar, and the project developers recognized was still there. What had changed was the chain of authority behind the package being delivered to them.

Modern software depends on that chain. Applications are assembled from libraries, frameworks, build tools, and packages maintained by people all over the world. Each installation assumes that the software delivered through a registry is the software its maintainers intended to publish.

2. Incident Overview

2.1 Incident record

This section records the technical facts from the incident record, with a confidence rating for each claim. Each claim carries a confidence rating — Confirmed, Supported, Plausible, or Not established (definitions in Appendix B).

Origin of the public report

The public incident began with GitHub issue #15, opened on 2026-05-14 at 15:01:21Z, titled "[SECURITY][REPORT] [email protected] CJS bundle contains obfuscated infostealer payload." The report states that malicious code had been appended to the CommonJS bundle after the legitimate module.exports boundary.

The issue documents a package shasum for 12.0.1:

fe5d107b9d285327af579259a32977c4f475fa26

Affected versions

Version 9.1.6 was added in a contemporaneous GitHub issue discussion, and it is confirmed affected in the incident record. Version 9.2.3 was reported by an independent investigator in a GitHub issue, and it is confirmed affected in the incident record. Version 12.0.1 is documented by the original issue and technical analysis, and it is confirmed affected.

Release timing

The investigation record reports a rapid three-release sequence: 12.0.1, followed ~30 seconds later by 9.2.3, then ~30 seconds later by 9.1.6. The comment gives a first clock time of 14:25:30

Entry point and execution condition

The issue states that the malicious code existed in node-ipc.cjs, the CommonJS entry point, while the ESM entry point node-ipc.js and other source files were clean. That distinction matters operationally: package presence alone was not equivalent to malicious execution. The highest-risk condition was a consumer environment that resolved an affected npm version and then loaded the compromised CommonJS path.

Verification in the issue thread

A researcher responding to the issue reported manually confirming the compromise and notifying npm security. The same thread identified 9.2.3, 12.0.1, and then 9.1.6 as affected.

2.2 Timeline

After researchers identified the malicious releases, the incident progressed quickly, moving from malicious publication to public investigation and containment within two days.

2026-05-07 — atlantis-software.net registration created

The current registration for atlantis-software.net was created at 11:49:33Z, as observed in preserved WHOIS output (evidence strength: High). The domain had lapsed and later returned under new control (WHOIS/DNS detail and the re-registration dates are in Section 5.2).

2026-05-14 07:26:10Z — azurestaticprovider.net creation observed in WHOIS

The creation timestamp for azurestaticprovider.net was observed in WHOIS (evidence strength: High). The domain family is associated with sh.azurestaticprovider.net, the resolver/C2-related host; the creation timestamp falls on the same date as the malicious node-ipc publication, though timing alone does not establish operator identity (WHOIS/DNS detail in Section 4.6).

2026-05-14 14:25:30 — First malicious publish

An investigator reported the first malicious publish (12.0.1), followed by 9.2.3 and then 9.1.6 at ~30-second intervals (evidence strength: Medium/High; investigator report). The record gives a first clock time of 14:25:30.

2026-05-14 15:01:21Z — GitHub security issue #15 opened

The public incident began with GitHub issue #15, opened at 15:01:21Z (evidence strength: High). The title and the package shasum are recorded in Section 2.1.

2026-05-14 — Independent confirmation and npm security notification

An independent investigator reported manually confirming the compromise and notifying npm security (evidence strength: High). The same issue thread identified 9.2.3, 12.0.1, and then 9.1.6 as affected, expanding the affected version set.

2026-05-15 — Evidence screenshots preserved

WHOIS, npm/GitHub profile, and DNS screenshots were preserved during the investigation (evidence strength: High). These correspond to the compiled investigation screenshots (NODE-IPC.pdf, artifact E-02) and the original screenshot archive (Attachments.zip, artifact E-03).

2026-05-15 — Repository owner restricted write access

The repository owner reported restricting write access to himself (evidence strength: High as a first-party remediation statement).

2026-05-16 13:43 — Final preserved reply captured

Final preserved reply captured from [email protected] (SPF/DKIM pass) (evidence strength: High for mail infrastructure use). The evidentiary value is operational mailbox control, not confession (mailbox exchange and header detail in Section 5.2).

2026-05-19 16:02 -0400 — Preservation request sent to Namecheap

A preservation request was sent to Namecheap regarding atlantis-software.net (evidence strength: High) (preservation request and registrar response in Section 5.2).

2026-05-19 20:03Z — Namecheap acknowledges report

Namecheap acknowledged the report (evidence strength: High) and stated that it would be reviewed (preservation request and registrar response in Section 5.2).

2026-05-22 20:51Z — Namecheap: allegation not validated

Namecheap said the allegation could not be validated from the supplied evidence and that legal process is required for preservation (evidence strength: High) (preservation request and registrar response in Section 5.2).

Containment timing

The incident was contained within two days: on 2026-05-15 the repository owner restricted write access to himself, and the evidence (WHOIS, npm/GitHub profile, and DNS screenshots) was preserved the same day.

3. Impact Assessment

3.1 Developer environments as a target

A developer laptop is rarely just a laptop, and a CI runner is rarely just a machine that runs tests. These environments sit at the intersection of an organization's code, credentials, infrastructure, and release process. They may be able to reach private repositories, cloud services, deployment platforms, package registries, Kubernetes clusters, internal databases, and production-adjacent systems.

That makes the development environment an attractive place for a supply-chain attack to land. The attacker does not need to discover every service from the outside if the compromised code runs somewhere those services are already trusted. Existing permissions, configuration files, tokens, and automation can turn the development environment into a map of the organization around it.

This is why a small dependency can produce outsized concern. The package itself may represent only a tiny fraction of an application's codebase, but its position inside the development process can give it proximity to systems far more valuable than the package itself.

A useful analogy is not a thief breaking into every building on a street, but someone compromising the courier who already has keys, routes, and permission to enter.

Open-source software works because developers do not build everything themselves. A modern application may rely on hundreds or thousands of components maintained by people the application team will never meet. This arrangement lets small teams build large systems by inheriting years of work from the ecosystem around them.

They inherit something else as well. Every dependency brings assumptions about who controls it, how releases are published, and what the package will be allowed to do once it reaches a developer workstation or CI environment. Most of those assumptions remain invisible until one of them fails.

The malicious node-ipc releases were designed to inspect developer and CI environments for sensitive information. Their targets were developer and CI credentials and configuration (the full collection-target breakdown is in Section 4.2). These were not simply interesting files on a machine; many represented access to the systems developers use to build, deploy, and operate software.

That proximity is what gave the compromise its reach. A third-party package running in a development environment may sit only a few steps away from private repositories, cloud accounts, deployment infrastructure, and production-adjacent systems. The dangerous part of a malicious dependency is therefore not only the code inside it, but the environment that agrees to run it.

A compromised dependency does not need to attack every downstream system directly. If it reaches an environment that already possesses legitimate access, some of the hardest work has already been done for it.

The value of the target lay not in the package contents but in the environments that would execute it.

3.2 How trust propagates through the supply chain

The node-ipc incident crossed layers that software teams manage as separate problems. A maintainer identity can possess publishing rights. Publishing rights determine what appears in a registry. The registry supplies software to developer machines and CI systems. Those systems contain credentials and configuration. Those credentials can lead to larger environments.

Seen that way, node-ipc was not only an npm incident. It was an identity incident, a distribution incident, and a developer-security incident. Each layer inherited confidence from the one before it. The package was trusted partly because the registry delivered it; the registry release was trusted partly because valid publishing authority had produced it; the code was allowed to run because all of those earlier assumptions normally hold.

For a broader threat-model perspective on how supply-chain compromises propagate across trust boundaries, see StepSecurity's writeup.

This is both the strength and the weakness of modern software reuse. Developers can build extraordinary systems because they do not have to renegotiate every trust relationship from first principles each time they install a package. But the same efficiency means risk can also be inherited.

This does not argue against open source; modern software development would be nearly impossible without it. It does argue for treating trust as something to be re-verified over time, because a package can deserve confidence for years and still become dangerous if control of its publishing path changes.

3.3 Capability vs impact & exposure states

The incident should be evaluated as a sequence of increasingly strong impact states, rather than as a single binary outcome. Each state proves something different, and the investigation's confidence in each state differs accordingly.

The "Malicious version published" state proves that a supply-chain compromise exists, with a status of Confirmed in this investigation. The "Package selected/downloaded" state proves potential consumer exposure, with a status of Environment-specific in this investigation. The "Compromised CJS loaded" state proves that the malicious runtime path was reached, with a status of Requires victim evidence in this investigation. The "Collection observed" state proves that host secrets were actually read, with a status of Requires victim evidence in this investigation. The "Archive staged" state proves that the collection pipeline progressed, with a status of Requires victim evidence in this investigation. The "DNS-exfiltration queries emitted" state proves that an exfiltration attempt occurred, with a status of Requires DNS/host evidence in this investigation. The "Remote receipt proven" state proves that the attacker received victim data, with a status of Not established in this investigation.

This distinction is operationally important for incident response. A host that merely contains a malicious package may warrant investigation and secret rotation based on risk, but the forensic statement should not be upgraded to "confirmed data theft" without supporting telemetry. Stages marked Requires victim evidence or Not established cannot be asserted from the package contents alone; they depend on host-level telemetry (process, filesystem, and DNS records) specific to each affected machine. Where that evidence is absent, the correct statement is a risk-based recommendation, not a confirmed impact claim.

The boundary between capability and impact is the core of this assessment. A malicious package that contains credential-collection and DNS-exfiltration code demonstrates what the payload can do; it does not by itself prove that a specific consumer executed the payload, that credentials were collected from that consumer, or that data was successfully received by a remote operator. Capability is established from the code; impact requires evidence from the victim environment. Conflating the two overstates the incident and can misdirect response effort.

4. Technical Analysis

This section reconstructs the technical behavior documented in the public incident record for the affected node-ipc releases (9.1.6, 9.2.3, 12.0.1). It separates what the code is demonstrated to do from what cannot be concluded without host, DNS, or receiver-side evidence.

4.1 Entry point and execution condition

The malicious code was appended to node-ipc.cjs, the CommonJS entry point, while the ESM entry point node-ipc.js and the other source files were clean (documented in Section 2.1). This distinction matters operationally: package presence alone was not equivalent to malicious execution, and the highest-risk condition was a consumer environment that resolved an affected version and then loaded the compromised CommonJS path. The full exposure sequence and the capability-vs-impact boundary are assessed in Section 3.3.

4.2 Reconnaissance and credential collection

The incident report documents a range of credential-collection targets.

The targets include the OS platform, architecture, hostname, home directory, and temporary directory, which establish the host's identity and layout for the operator. The uname -a output adds kernel and build details to that host profile. The process ID and working directory pin down where the process is running from. All environment variables may contain credentials, tokens, and configuration. The /etc/hosts file can reveal internal network mappings. SSH keys and configuration provide direct access to private repositories and servers. Shell history and profiles may expose commands, hosts, and inline secrets. Cloud-provider credentials and configuration grant access to cloud accounts and infrastructure. Kubernetes configuration can reach cluster workloads and secrets. Application and developer configuration often embeds connection strings and API keys. Source-control and package-management material exposes credentials for repositories and registries. Other files likely to contain secrets cover additional secret-bearing files the operator may value.

This establishes collection capability. It does not establish which of these files actually existed on any specific victim host.

4.3 Staging and encoding

The payload was reconstructed as building a tar archive with a custom implementation and compressing the result with zlib.gzipSync(). The public reconstruction shows staging beneath a temporary nt-* path and includes a manifest-like _paths.txt file.

This design minimizes the number of independent outbound operations: many local files are normalized into a single compressed object before exfiltration.

4.4 DNS exfiltration design

The reconstructed code uses DNS query names as the data channel. It divides encoded archive material into chunks and constructs a header/data/footer sequence using three short prefixes.

For an independent breakdown of this payload and its DNS exfiltration mechanism, see Datadog Security Labs' malware analysis.

The xh prefix denotes the header, the xd prefix carries the data chunks, and the xf prefix denotes the footer.

The issue discussion identifies sh.azurestaticprovider.net as the resolver/C2-related host and bt.node.js as the query suffix used by the reconstructed protocol.

The practical detection lesson is that defenders cannot restrict their analysis to DNS answers. The query name itself is the payload carrier.

4.5 Process behavior and cleanup

The public incident analysis reports a detached child process, environment guards such as __ntw / __ntRun, and deletion of staged temporary material. Those behaviors support stealth and execution separation.

The available evidence does not establish a durable autorun or persistence mechanism. Detaching a process from its parent is not, by itself, persistence across reboot or login.

4.6 C2 and DNS infrastructure investigation

The investigation also preserved WHOIS and DNS observations for azurestaticprovider.net, the domain family associated in the GitHub issue with sh.azurestaticprovider.net.

The captured WHOIS result records the details of the domain as observed during the investigation.

The creation date is 2026-05-14T07:26:10Z, the registrar is NICENIC INTERNATIONAL GROUP CO., LIMITED, the nameservers are NS3.MY-NDNS.COM and NS4.MY-NDNS.COM, and the registrant is privacy-redacted.

The creation timestamp falls on the same date as the malicious node-ipc publication. The same investigation captured DNS responses for the domain and its authoritative nameserver set.

The timing is suspicious and technically relevant, but timing alone does not establish operator identity. Likewise, later DNS misconfiguration or inconsistent referrals cannot prove evasive intent.

5. Attribution & Evidence

5.1 Maintainer identity & publishing path

Introduction

The strongest public connection between the malicious npm artifacts and a maintainer identity appears in the issue #15 investigation thread. Investigators reported that the malicious tarballs contained:

_npmUser: atiertant

with the associated email:

[email protected]

One investigator described this as a likely "Email Takeover." A later comment explicitly acknowledged uncertainty: the domain had expired, it was registered again, and the attacker likely used the mailbox to reset the npm password. That distinction matters. The evidence supports a plausible recovery path but does not establish the exact mechanism of npm account takeover.

What the evidence supports

atiertant was a known maintainer identity associated with node-ipc. Investigators reported that the malicious tarballs carried atiertant npm publisher metadata. The public/display email associated with that npm identity used atlantis-software.net. The domain was under a new/current registration before the malicious publication. PrivateEmail infrastructure was configured and the mailbox was demonstrably capable of sending authenticated mail after the incident.

What the evidence does not include

npm password-reset records, which would directly show whether a recovery was performed, are absent from the evidence. npm login IPs, which could place an actor at the publisher account, are not included. npm MFA/recovery logs, which would distinguish login from recovery and show which channels were used, are missing. A registrar account login history tying domain control to the npm publisher session, which is needed to connect domain control to the publishing event, is not available. Human identity evidence for the mailbox operator, which would move attribution beyond infrastructure control, is lacking.

The absence of these artifacts means the chain from domain reacquisition to a concrete npm password reset is inferred, not directly observed. Where a claim rests on inference rather than a preserved record, this document marks it as plausible rather than confirmed.

Github profile evidence

Common DevOps security researcher (Aaron Schneider) screenshot preserved the GitHub profile associated with atiertant during the investigation (source: original May 2026 screenshot archive). This capture is contextual evidence only. It establishes how the account and its associated projects appeared at the time, but it does not prove that the GitHub account itself was compromised or used to publish the npm malware.

The consolidated root-cause statement is given in Section 6.

5.2 Domain, email & registrar evidence

atlantis-software.net registration

The WHOIS capture preserved by the investigator records the details of the domain visible during the incident.

The domain was ATLANTIS-SOFTWARE.NET. The registrar was Namecheap, Inc. The creation date was 2026-05-07T11:49:33Z. The nameservers were DNS1.REGISTRAR-SERVERS.COM and DNS2.REGISTRAR-SERVERS.COM. The registrant details were privacy-protected.

This capture materially strengthens the 2026-05-07 date. It is a snapshot of registry/registrar output taken at the time, not a later narrative recollection.

Conflicting re-registration dates

A GitHub comment elsewhere in the incident thread asserted a 2026-03-10 re-registration date. A later investigator comment stated 2026-05-07 and said the exact prior expiry could not be determined. The primary WHOIS capture and the subsequent preservation request both support the 2026-05-07 creation timestamp for the registration visible during the incident.

Conclusions

The current registration's creation timestamp was observed at 2026-05-07T11:49:33Z, with high confidence. The exact date the prior registration expired is not established by the preserved evidence. The historical "re-registration" chronology before 2026-05-07 is not fully established from the preserved evidence.

Direct exchange with the mailbox

A preserved six-message thread shows the repository owner emailing [email protected] after the incident became public. Replies were received from that address. The exchange included short responses such as "meow" and "hehe." The owner then asked whether the sender had acquired the server and found credentials. The final reply was "Sayonara, friend."

The evidentiary value here is operational mailbox control, not confession. The final response does not admit server acquisition, password recovery, npm access, or malware publication.

Authentication of the final reply

The original-message export for the final reply records:

The Message-ID was <[email protected]>. It was created on 2026-05-16 at 1:43 PM. The From field was [email protected]. The mailer was Open-Xchange Mailer v7.10.6-Rev91. SPF was PASS with IP 198.54.127.77. DKIM was PASS with domain atlantis-software.net. DMARC was FAIL.

SPF/DKIM success is meaningful because it shows the message was sent through infrastructure authorized for the domain and carried a valid domain signature at that time. It does not authenticate the human identity of the sender. Domain control and identity are separate propositions.

Preservation request and registrar response

On 2026-05-19, a preservation request was sent to Namecheap regarding atlantis-software.net. It supplied the observed registration timestamp, the relevant mailbox, an incident link, three PrivateEmail Message-IDs, and two outbound relay observations.

The request asked Namecheap to preserve several categories of records.

Domain registration-account details would identify who registered and controlled the domain. Registrar login IPs and user agents could place an actor at the account. Account creation, recovery, and password-reset events are central to testing whether the domain mailbox was used to recover the npm account. DNS and mail-record history would show when authoritative records were configured for the new registration. Mailbox creation time helps date when the operational mailbox came into use. Webmail sessions could tie a human operator to the mailbox. SMTP submission logs corroborate the preserved outbound relay observations. DKIM signing records support authentication of the preserved replies. Support/recovery records may document recovery actions taken on the account. Related abuse or fraud flags would indicate prior warnings to the registrar.

Namecheap acknowledged receipt on 2026-05-19 and stated that the report would be reviewed.

On 2026-05-22, Namecheap responded that it had investigated "to the extent of our capabilities" but could not validate the allegation from the supplied evidence. It requested additional evidence and stated that preservation requests are processed upon receipt of a U.S. court order or subpoena by the Senior Legal department.

Legal/evidentiary boundary

A preservation request was submitted. Namecheap acknowledged and reviewed it. The available correspondence does not establish that the requested records were preserved. No registrar account, webmail-session, or npm-recovery logs were obtained through this process.

6. Root Cause Analysis

6.1 Unmonitored identity infrastructure

Summary

Publication metadata pointed investigators toward a dormant maintainer identity associated with an address at atlantis-software.net. The domain had lapsed and later returned under new control, and investigators found working mail infrastructure for it after the incident. Publishing authority can outlive the person or organization that originally created it.

Unmonitored identity infrastructure

A publishing account is not secured only by its current password or MFA configuration; it can also depend on old email addresses, old domains, recovery workflows, collaborator lists, and permissions that nobody has reviewed in years. When those pieces remain connected, abandoned identity infrastructure can quietly remain part of the software supply chain. A forgotten maintainer domain was not merely a web property that had expired. It was part of an identity chain connected to package publishing.

Dormant publishing authority as a risk

Dormant publishing authority is security debt. So are expired domains, forgotten recovery addresses, and contributors who still possess privileges long after their role in a project has ended.

Dormant identities remain exploitable even after they are no longer actively managed.

6.2 Root-cause statement

The demonstrated chain runs from valid npm publishing authority through malicious npm versions, vulnerable dependency resolution, a compromised CommonJS execution path, and finally to credential collection and DNS-exfiltration capability; the identity chain runs from a lapsed maintainer email domain to a new registration, mailbox operation, npm account recovery, and the use of publisher authority. The step-by-step confidence assessment for each link is given in Section 3.3.

The evidence directly supports:

Unauthorized use of valid npm publishing authority associated with a maintainer identity allowed malicious package artifacts to enter the official distribution channel.

7. Detection & Indicators

7.1 Package and file indicators

9.1.6, 9.2.3, and 12.0.1 are the three affected npm versions confirmed to contain the malicious CommonJS path. node-ipc.cjs is the compromised CommonJS entry point, while the ESM entry point node-ipc.js and the other source files were clean. The npm shasum fe5d107b9d285327af579259a32977c4f475fa26 is reported for 12.0.1 in issue #15. An unexpected appended obfuscated IIFE after the legitimate bundle marks where the payload was inserted, after the legitimate module.exports boundary. (The affected versions, shasum, and entry-point facts are documented in Section 2.1.)

7.2 Runtime indicators

The child environment marker __ntw=1 is one of the environment guards reported in the reconstruction. The __ntRun guard/export marker reported in the reconstruction signals the payload's execution-guard behavior. The temporary nt-* staging directory is where staged archive material was placed before exfiltration. A collection of envs.txt, uname.txt, /etc/hosts, keys, history, and cloud/developer configuration reflects the credential-collection targets the payload attempted to read. A Node.js child process detached from the parent separates the malicious execution from the invoking process.

7.3 Network indicators

sh.azurestaticprovider.net was identified in the issue discussion as the resolver/C2-related host. azurestaticprovider.net is the domain family associated with that C2 host, newly registered around the publication date. The DNS query-name suffix bt.node.js is the query-name suffix used by the reconstructed exfiltration protocol. The query prefixes xh, xd, and xf are the header/data/footer prefixes of the DNS query-name encoding. Anomalously long, high-entropy DNS labels signal encoded archive material carried in the query name rather than a normal lookup. Node.js processes sending DNS traffic to non-standard or explicitly configured resolvers indicate exfiltration attempts directed away from approved resolvers. (The C2/DNS infrastructure detail is in Section 4.6.)

7.4 Detection priorities

The highest-value defensive data sources are:

1. Dependency lockfiles, SBOMs, and package caches — let defenders confirm which environments resolved an affected version.
2. Process/module telemetry identifying CommonJS loads — can show whether the compromised entry point was actually loaded.
3. File-access telemetry around SSH/cloud/Kubernetes credentials — reveals whether credential files were read.
4. Temporary-directory creation/deletion — matches the nt-* staging behavior.
5. DNS logs retaining full query names are required because the query name itself carries the exfiltrated data.
6. Firewall telemetry showing DNS outside approved resolvers. Catches queries directed at the C2 host.
7. Credential-provider logs showing anomalous reuse after potential exposure. Detect whether exposed credentials were later used.

For detection signals and a package-level timeline, see Socket.dev's analysis.

8. Remediation & Recommendations

No development team can realistically inspect every line of every dependency it uses, and perfect inspection would not solve the larger problem anyway. Software changes continuously. Maintainers change, releases change, account ownership changes, infrastructure changes, and dependencies acquire dependencies of their own. Security has to survive those changes rather than assume they will never happen.

8.1 Corrective & Preventive Actions

The incident exposes a chain of trust assumptions that can be broken at several points: who is authorized to publish, what credentials the package can reach, and how a malicious release is detected and contained. The actions below are grouped by horizon.

Immediate

Remove or disable stale npm publisher identities, and give old collaborator accounts and maintainer domains proper lifecycle management so dormant identities are removed rather than left behind. Rotate credentials present on systems that executed affected CommonJS versions, to limit what a compromised host can do with them. Hunt package caches, lockfiles, CI environments, and developer workstations for affected versions, so every environment that may have resolved the malicious artifacts is identified. Block or investigate the documented DNS indicators, to contain and detect exfiltration attempts. Preserve relevant DNS, process, endpoint, and identity telemetry, so that host-level evidence can be correlated later.

Near term

Require phishing-resistant MFA for publisher accounts where available, to reduce the chance a publisher account is taken over via credential theft. Review account-recovery channels separately from login MFA, because recovery is a distinct path that login MFA alone does not protect. Inventory maintainer email domains and alert on expiration or ownership changes, so a lapsed domain can be detected before it is re-registered by someone else. Minimize long-lived secrets in environment variables and developer home directories; every secret available to the environment is potentially available to code running inside it. Restrict DNS egress to approved resolvers, to block exfiltration directed at non-standard resolvers. Detect high-entropy DNS query labels and non-standard DNS destinations, because the exfiltration encoded data into unusually long query names. Compare published package contents against expected source/build artifacts, and scrutinize unexpected releases that do not correspond to expected source history.

Strategic

Establish formal publisher lifecycle governance, and treat publishing access for critical packages like production access—limited, reviewed, and removed when it is no longer necessary. Create rapid package-takedown and maintainer-notification procedures, to shorten the time a malicious release stays available. Require provenance or verifiable build relationships for critical packages, so consumers can confirm a release matches its claimed source. Perform exercises that treat dependency compromise as both a software and identity incident, because the publishing path—not just the code—is what must be defended.

8.2 Trust-path analysis

A dependency incident should therefore trigger a broader question than "Which version did we install?" Teams also need to ask what the package could reach, what credentials were present, where those credentials led, and what assumptions allowed the package to run there in the first place.

Moving from package inventory to trust-path analysis is a key recommendation from this incident.

9. Lessons Learned

9.1 Exploiting existing trust

The node-ipc incident showed how ordinary its starting point was. There was no need for the package name to change, no need for developers to adopt an unfamiliar tool, and no need for the upstream project to suddenly look obviously hostile. The attack could benefit from trust that had already been earned.

That is the defining advantage of a software supply-chain attack. Rather than breaking into each system individually, it can compromise something an organization has already chosen to trust and run.

9.2 Trust is a property of the supply chain, not the package name

Open source runs on that invitation. Developers build on one another's work because the ecosystem makes reuse cheap, fast, and usually dependable. That model is not going away, nor should it. But the model works only if teams understand that trust belongs to a chain of people, identities, registries, tools, and runtime environments—not to a package name alone.

The node-ipc compromise was therefore more than a set of malicious releases. It demonstrated that familiar software carries the authority of everything behind it: the maintainer who can publish it, the registry that distributes it, the tooling that installs it, and the environment that permits it to run.

These trust relationships are normally not visible to the teams that depend on them; the incident made them visible on 2026-05-14.

9.3 Findings at a Glance

The finding "Malicious npm artifacts published" is assessed as Confirmed, with High confidence. The finding "CommonJS distribution contained appended payload" is assessed as Confirmed, with High confidence. The finding "Credential collection capability" is assessed as Confirmed, with High confidence. The finding "DNS query-name exfiltration capability" is assessed as Confirmed, with High confidence. The finding "Valid maintainer publishing authority abused" is assessed as Supported, with High confidence. The finding "Email-domain recovery caused npm takeover" is assessed as Plausible, not proven, with Medium/Low confidence. The finding "Successful victim data receipt" is assessed as Not established, with Unknown confidence. The finding "Human actor attribution" is assessed as Not established, with Unknown confidence.

9.4 Conclusion

The 2026 node-ipc incident shows how a software supply-chain event can begin as an identity and publishing-authority failure and end as malicious code executing inside trusted developer or CI contexts.

The malicious behavior itself is technically well supported: compromised CommonJS artifacts, credential collection, archive staging, and DNS query-name exfiltration were documented in the public incident response. The independent investigation adds a separate evidentiary layer: a newly/currently registered maintainer email domain, an operational PrivateEmail mailbox, authenticated replies from that domain, contemporaneous WHOIS and DNS captures, and a documented attempt to preserve registrar and email-provider records.

Those facts make an email-based account-recovery compromise likely.

For independent analyses of this incident, see Datadog Security Labs, Socket.dev, and StepSecurity.

Appendix A — Known Unknowns

The following questions remain open; the current evidence does not justify closing these gaps through inference.

What exact npm authentication or recovery event preceded the malicious publication? No npm login or recovery telemetry is on file to identify that event.

Which IP addresses, devices, and user agents accessed the npm publisher account? No npm access logs were preserved to identify the systems involved.

When did the previous atlantis-software.net registration lapse, and what is the complete historical registration chain? The preserved WHOIS shows only the current registration, not the prior history.

Who controlled the re-registered domain and mailbox? Registrant details are privacy-protected and no operator identity is on file.

Did any specific victim execute the malicious CommonJS path? No victim-specific telemetry confirms execution on a given host.

Did any victim emit the DNS exfiltration sequence? No DNS or host evidence shows the sequence leaving a victim machine.

Did the remote operator successfully reconstruct or receive victim archives? Receiver-side evidence is absent, so remote receipt is not established.

Can a specific person or group be attributed from evidence stronger than infrastructure control? Attribution currently rests on infrastructure control, which alone does not identify an actor.

Appendix B — Scope, Evidence Method & Register

B.1 Scope

This report reconstructs four related questions. It asks what malicious behavior was present in the affected node-ipc npm releases. It asks what evidence connects the publication event to a maintainer publishing identity. It asks what the independent domain, DNS, and email investigation established. It also asks which causal claims are supported, plausible, or still unresolved.

The report does not attempt to identify a specific human actor. It also does not claim victim compromise without victim-specific telemetry.

B.2 Evidence classes

The analysis uses three evidence classes.

The Primary / direct class consists of original records or contemporaneous artifacts, such as GitHub issue/comments, original screenshots, original email thread, full message headers, and Namecheap correspondence. The Corroborating technical class consists of independent technical observations consistent with primary evidence, such as package reconstruction in the issue, DNS/WHOIS observations, and npm/GitHub profile captures. The Inference class consists of an explanation that connects established observations, such as domain reacquisition used for npm password recovery, operator identity, and motive.

A primary record can still contain an investigator's hypothesis. The classification applies to the claim, not simply to the document containing it.

B.3 Confidence language

Confirmed / High means the claim is directly supported by primary evidence or multiple independent observations. Supported / Medium means the evidence is consistent and meaningful but incomplete. Plausible / Low means a reasonable explanation where a required causal link is absent. Not established means the available evidence does not support the claim.

B.4 Evidence register

B.5 Primary source notes

GitHub Issue #15 https://github.com/RIAEvangelist/node-ipc/issues/15

Use of the issue is claim-specific. Technical observations from the original report are treated as primary incident-analysis evidence. Investigator statements about account takeover remain investigator hypotheses unless independently supported.

Email evidence SPF and DKIM results demonstrate authorized domain-mail infrastructure use for the preserved message. They do not identify the human sender.

WHOIS/DNS screenshots The screenshots document what queried services returned during the investigation. They do not prove historical state outside the query time, actor ownership, or malicious intent.

Preservation correspondence The correspondence proves submission, acknowledgement, and Namecheap's stated legal-process requirement. It does not prove that preservation occurred.

Appendix C — About the Authors

C.1 Who we are

This report was produced by Common DevOps. Independent analysis led by security researcher Aaron Schneider, with assistance from Dr. Ian Miller and Javier Bonilla. We are the authors of this incident paper.

The initial issue and subsequent coordinated investigation started when @nullcharb (Ahmed) opened GitHub security issue #15. First reported to NPM by @carlini (Nicholas Carlini)

Full list of investigators: @RIAEvangelist @nullcharb @carlini @ashishkurmi @cyb3rjerry @Roni-Carta @jimmytsadiotis @danielweck

C.2 How we became involved

We first learned about the node-ipc compromise through public reporting. We went to the primary source, GitHub security issue #15 and its thread, to engaged directly. From that starting point we conducted an independent investigation into the domain, DNS, email, and registrar evidence surrounding the incident. In addition, we interviewed Brandon Miller (RIAEvangelist), the repo owner.

C.3 What we did

• Independent domain, DNS, and email/registrar investigation.

We examined atlantis-software.net (WHOIS, nameservers, registration timing) and azurestaticprovider.net, analyzed mailbox control, and assessed message authentication (SPF/DKIM/DMARC).

• Preserved contemporaneous evidence.

We retained WHOIS and DNS captures, npm/GitHub profile screenshots, the preserved email thread, and an original-message header export.

• Submitted a preservation request to Namecheap on 2026-05-19, requesting registrar account details, webmail sessions, and related records.

We documented their 2026-05-22 response and the legal-process (court order / subpoena) boundary for preservation.

• Compiled the evidence register (E-01 through E-09) and produced this structured, confidence-rated report.

C.4 Scope and boundaries

Where evidence was insufficient we marked the claim as Plausible or Not established rather than asserting it (full scope statement in Appendix B, Section B.1).