node-ipc — three poisoned versions, an expired domain mailbox, and 90 categories of leaked credentials

TL;DR — 90 seconds

Three node-ipc versions with an active credential stealer were live in the npm registry for eleven hours on 14 May 2026; the initial vector is an expired maintainer mail-domain mailbox, exfiltration runs over DNS TXT tunnelling — anyone who built in that window rotates now.

What is the problem?

node-ipc is a Node.js library for inter-process communication, maintained since 2014. With around 822,000 weekly downloads and roughly 3.35 million monthly downloads, the library is one of the most commonly pulled-in transitive npm components — it sits beneath Webpack (using node-ipc for IPC between watcher and dev server), beneath Vite (development IPC), beneath vue-cli and beneath several tooling paths that travel with TYPO3 sitepackage build pipelines and Sylius frontend build pipelines. Directly installed, node-ipc appears in only a handful of German Mittelstand projects; transitively installed, in practically every contemporary TYPO3 13+ or Sylius 2+ sitepackage.

Between roughly 03:00 UTC on 14 May 2026 and the registry takedown that afternoon UTC, three tampered versions — 9.1.6, 9.2.3 and 12.0.1 — were available on the npm registry. All three carried an identical obfuscated JavaScript payload of about 80 KB, triggered through the postinstall lifecycle and through the module execution path on the first require('node-ipc'). The payload decompressed itself, scanned the build host across more than 90 categories of credentials, and exfiltrated the values it found via DNS TXT queries to a lookalike domain impersonating Azure infrastructure (sh.azurestaticprovider.net, routing zone bt.node.js, query prefixes xh, xd, xf).

The decisive point is not the payload but the initial vector. The attacker did not compromise the npm account (no brute-force password reset, no OAuth token theft), did not infiltrate the maintainer's machine, and did not exploit a vulnerability in the registry. They re-registered the domain atlantis-software.net through Namecheap on 7 May 2026, after it had expired the previous day, configured a PrivateEmail mailbox under the original maintainer's mailbox name, and used it to walk through npm's regular account-recovery path. In this model the maintainer identity is not the account but the mailbox at the key symbol. Whoever owns the mailbox is the maintainer.

This is the structural weakness that distinguishes this episode from Mini-Shai-Hulud (OIDC memory extraction from CI runners) and from the Composer token leak (diagnostic output). Mini-Shai-Hulud was a technical attack on the CI pipeline layer. Composer was a validation weakness on the build-tool layer. node-ipc is an administratively clean account takeover: every step of the attack ran through the regular, documented paths of the registry and the maintainer-account system. It cannot be defended through a patch — it can only be defended through discipline in the relationship between identity and backup channel.

Who is affected?

A compact overview of affected and non-affected configurations.

Anyone who ran multiple builds in the 11-hour window — typical for a TYPO3 tenant platform with frequent sitepackage pushes — has potentially executed the stealer several times, exfiltrating a fresh snapshot of the credential pool each time. We treat the estate operationally as “credentials leaked unless proven otherwise” and follow the audit path: lockfile inventory first, then hash audit of the package-lock.json estate, then build-host credential rotation, then pipeline token reissue.

Impact

The operational severity comes from three factors: the credential pool on a typical build host, the exfiltration path, and the structural mode of the attack.

The credential pool on a platform build host in the German Mittelstand is wide by experience. AWS access keys or Azure service principals for cloud deployments, GitHub CLI config with refresh token, SSH keys for tenant hosting targets, Kubernetes kubeconfig for cluster rollouts, Terraform state with cloud secrets, database passwords in CI variables, shell history with command-line-pasted tokens. The Datadog analysis of the payload lists more than 90 categories, including explicitly Claude AI and Kiro IDE settings — the stealer line has adapted to the reality of a contemporary developer workstation.

The exfiltration path is DNS TXT tunnelling, not HTTP/HTTPS. That is the operationally most uncomfortable layer of the episode: standard egress firewalls on cloud build hosts or self-hosted runner VLANs typically let DNS through because build tools need DNS for module resolution. A 500 KiB compressed archive generates roughly 29,400 DNS TXT queries to the lookalike domain — visible on a DNS query logging layer, but not in a standard firewall view. This is the same pattern known from DNS exfiltration research but rarely seen in a production npm stealer.

The structural mode is the biggest lesson. An attacker with the domain takeover as the only vector did not brute-force any account, did not steal any OAuth token, and did not find any security flaw in the registry. They walked the lookup path “email domain → mailbox → npm account recovery → publish right” cleanly. That makes the episode hard to address on the defender side: every defence layer would have to anchor the maintainer identity not in the email domain but in a second identity layer (hardware key, GPG signature, MFA backup-code discipline). In the npm ecosystem this is mostly not the standard today.

Business impact of a successful credential exfiltration on a tenant platform is in the worst case direct access to tenant cloud resources, deployment targets and tenant pipeline tokens. That is the lead-in for targeted follow-on attacks (lateral movement into the tenant environment, persistent backdoor installation), not full intrusion — but in a typical DACH platform setup with tenant-specific cloud sub-accounts the impact has to be assessed separately for each tenant.

Mitigation / immediate actions

Three paths, depending on pipeline discipline.

Path 1 — Lockfile audit and pin to the clean line

First layer: lockfile inventory across the entire tenant estate.

# Check all package-lock.json in the estate for node-ipc versions
find /path/to/projects -name "package-lock.json" -type f \
  -exec sh -c '
    for f; do
      if grep -lE "\"node-ipc\":\s*\"(9\.1\.6|9\.2\.3|12\.0\.1)\"" "$f" > /dev/null; then
        echo "HIT: $f"
      fi
    done
  ' sh {} +

# Check pnpm-lock.yaml / yarn.lock in parallel
grep -rEHn "node-ipc.*(9\.1\.6|9\.2\.3|12\.0\.1)" \
  /path/to/projects --include="pnpm-lock.yaml" \
  --include="yarn.lock" 2>/dev/null

On a hit, set the pin to the last clean line in package.json.

{
  "overrides": {
    "node-ipc": "9.1.5"
  }
}

For pnpm:

# pnpm-workspace.yaml
overrides:
  node-ipc: 9.1.5

Regenerate the lockfile and fix the override in the platform template until the maintainer line returns with a verified clean publish.

Path 2 — Invalidate build cache and module cache

The payload sits in the module graph. On every build host that ran in the window, the cache is potentially contaminated.

# Flush npm cache
npm cache clean --force

# Prune pnpm store
pnpm store prune

# Clean yarn cache
yarn cache clean

# Remove local node_modules across the board and reinstall
find /path/to/projects -name "node_modules" -type d -prune -exec rm -rf {} +

For GitHub Actions workflows, also invalidate the actions cache, because a cached node_modules layer can revive the payload on a subsequent run.

Path 3 — Credential rotation on affected build hosts

If a build ran in the 11-hour window and the stealer payload was therefore executed, the entire credential pool on the host must be treated as compromised.

# Rotate AWS access keys
aws iam create-access-key --user-name platform-build
aws iam delete-access-key --user-name platform-build --access-key-id <OLD>

# Regenerate SSH keys and remove the old public key from all tenant targets
ssh-keygen -t ed25519 -f ~/.ssh/platform_build_$(date +%Y%m%d) -N ''

# Rotate Kubernetes service account tokens
kubectl -n tenant-cluster delete secret build-sa-token
kubectl -n tenant-cluster create token build-sa --duration=24h

Token rotation at the cloud-provider level is tenant-scoped. If you run multiple tenant cloud sub-accounts in the platform, rotate per tenant and document the rotation in the tenant incident ledger.

Stopgap if the lockfile pin is not possible within the next 12 hours

Run builds temporarily with lifecycle scripts disabled:

# npm: install without postinstall scripts
npm ci --ignore-scripts

# pnpm
pnpm install --ignore-scripts

# yarn
yarn install --ignore-scripts

This variant also disables legitimate postinstall paths (for example native module builds for legacy node-sass or argon2 native builds), so it cannot run as a permanent solution. It buys time until the lockfile pin has cleared the platform pipeline.

Detection / verification

Three complementary paths.

Path 1 — SCA scan for the compromised versions

Standard SCA tools (Snyk, Socket, Dependabot, GitHub Security Advisories) have had the finding in their databases since 14 May 14:00 UTC. A fresh run against the tenant estate picks up the hits without further configuration.

# npm audit against the current database
npm audit --omit=dev

# Socket CLI for the external supply chain
socket scan create --repo your-org/your-repo --branch main

# Trivy filesystem scan against the source-code estate
trivy fs --severity HIGH,CRITICAL /path/to/projects/

The weakness of the SCA layer is timing. Anyone who ran the scan before 14 May 14:00 UTC did not find the result because the signature was not yet in the databases. The audit has to be run explicitly after 14 May 16:00 UTC to pick up the current signatures.

Path 2 — DNS query logs for the exfiltration pattern

Exfiltration runs via DNS TXT queries to the lookalike domainsh.azurestaticprovider.net with routing zone bt.node.js and query prefixes xh, xd, xf. DNS egress logging on the build hosts or at the recursive resolver layer catches the hits.

# Check bind/unbound query log for the pattern
grep -E "(azurestaticprovider\.net|\.bt\.node\.js)" \
  /var/log/named/query.log \
  | awk '{print $1, $2, $5, $7}'

# systemd-resolved log via journalctl
journalctl -u systemd-resolved \
  --since "2026-05-14 03:00:00" \
  --until "2026-05-15 00:00:00" \
  | grep -E "azurestaticprovider"

Path 3 — Falco rule for DNS exfiltration patterns on CI runners

Self-hosted runners with Falco can observe egress DNS queries via a custom rule.

# /etc/falco/rules.d/node-ipc-dns-exfil.yaml
- macro: dns_exfil_target_domains
  condition: >
    (fd.sip.name contains "azurestaticprovider.net" or
     fd.sip.name contains ".bt.node.js")

- rule: DNS exfiltration to node-ipc supply chain attacker domain
  desc: Process resolves attacker-controlled domains used in node-ipc compromise (May 2026)
  condition: >
    evt.type in (sendto, sendmsg) and
    fd.l4proto = udp and
    fd.sport = 53 and
    dns_exfil_target_domains
  output: >
    DNS exfiltration target hit: cmdline=%proc.cmdline target=%fd.sip.name
  priority: CRITICAL
  tags: [node-ipc, supply-chain, dns-exfil, may-2026]

For Kubernetes-driven platforms with a Cilium-Hubble stack the pattern can be observed in parallel as a Tetragon TracingPolicy. The reproduction is trivial — and dangerous. Anyone who wants to reproduce the payload must install the module in a fully isolated sandbox (no network egress, no credential pool on the host, a dedicated VM with a snapshot reset). Reproduction on a platform build host or a tenant CI pipeline is not acceptable, because the stealer scans the host comprehensively.

Operator recommendation

The operational question is not “which lockfile do we pin to which version?” but “which maintainer-identity discipline do we keep ready against the next comparable domain takeover?”. The node-ipc episode is an administratively clean account takeover. It will find imitators, and the next domain is the next weekly disclosure.

Operational Decision Block — immediate rotation vs. lockfile audit

• Rotate immediately when the tenant platform build ran a fresh npm install / pnpm install / yarn install against an unfrozen lockfile in the 11-hour window 14 May 03:00–14:00 UTC and node-ipc (directly or transitively) was in the module graph.
• Lockfile audit in the 24-hour corridor when lockfiles in the platform estate were frozen and no npm install with lockfile update ran — the pin to the clean line is enough; rotation on a suspicion basis only on build hosts with an unclear history.
• Awareness only when the tenant platform runs only PHP/Composer build pipelines and there is no Node frontend build in the stack — the episode stays on the skip list for the tenant architecture review.
• Maintenance window in the standard cycle is possible when the frontend build runs on a Wolfi base with its own Wolfi index that did not pass through the registry window — the pin is still recommended as a precaution.

German Mittelstand

Run a lockfile audit across all TYPO3 sitepackage repos and Sylius shop repos in the tenant estate. npm audit with an updated database signature (after 14 May 16:00 UTC), pin to node-ipc@9.1.5 or 12.0.0 as an override in package.json, cache invalidation on all build hosts. Build-host credential rotation on the machines that ran an npm install without a lockfile pin in the window — reissue AWS/Azure/GCP keys, SSH keys, Kubernetes tokens and GitHub CLI configs. A tenant awareness note for every tenant with an independent frontend build corridor; the GDPR follow-up assessment is tenant-scoped because the exfiltrated credentials may have covered tenant-specific cloud resources.

Enterprise

In addition to the Mittelstand line: SCA tool rescan across the entire build pipeline corpus, maintainer-identity audit across the curated npm dependency list, DNS egress filter on the CI build hosts (egress whitelist on registry mirrors and cloud API endpoints, all other DNS queries to a separate audit layer). Pre-receive hook on the central GitHub Enterprise server against lockfile drift in PRs, blocking any node-ipc@9.1.6/9.2.3/12.0.1 as a hard block.

Kubernetes platform

Anyone operating Actions Runner Controller (ARC) or Tekton as a CI platform has the advantage of central runner image definitions. Image promotion to a Wolfi base with a frozen Wolfi index that did not pass through the registry window — Helm chart pin to the runner image tag with a fixed Wolfi state. Roll out the Falco rule from the detection section cluster-wide; deploy a Tetragon policy in parallel on cluster platforms with a Cilium-Hubble stack.

• Sub-scenario ARC with curated Node images: lockfile pin in addition to the image pin, so that an accidental npm install without a lockfile pin does not pull in the compromised state.
• Sub-scenario Tekton pipelines with an npm-ci step: set --ignore-scripts as a default flag in the pipeline template until the maintainer line returns with a verified clean publish.

Declarative stacks (NixOS / Talos / Flatcar / Wolfi)

NixOS and Wolfi packages pin the index at build time. Anyone who froze the index before 14 May 03:00 UTC is not affected by default. Anyone who pulls the index dynamically (for example a nixos-unstable channel sync in the window) is potentially affected and must roll back the channel snapshot. Wolfi builds with a private npm mirror are not affected by default; Wolfi builds that pull directly from the public npm registry have to be treated like any other build host. Self-hosted runners on a Talos or Flatcar base inherit the pin with image promotion to a declaratively pinned Node line.

What we actually did

We ran four disciplines on 15 May 2026 between 06:00 and 09:00 CEST.

First the lockfile inventory: scanned every active TYPO3 sitepackage repo and Sylius shop repo in the tenant platforms via find plus grep across package-lock.json, pnpm-lock.yaml and yarn.lock. 31 repos came out, 27 of them with node-ipc in the transitive module graph (Webpack Encore in Sylius frontends, Vite in TYPO3 sitepackages, Storybook in two platform component libraries). In three repos the lockfiles already contained node-ipc@9.2.3 — the build host had run an automatic npm install for a TYPO3 sitepackage update run in the 11-hour window between 14 May 03:00 and 14:00 UTC.

Then immediate rotation on the three affected build hosts: reissued AWS IAM user access keys, rotated GitHub CLI configs (OAuth tokens revoked and reissued), replaced SSH keys on the tenant hosting targets (removed the old public keys from the tenants' authorized_keys), reissued Kubernetes service-account tokens for the affected tenant clusters. Sent tenant awareness notes to the three tenants whose platform repo was affected — with the specific time window, the affected credentials, and the state of rotation. Three tenant-specific incident ledgers opened.

Then the lockfile pin: switched all 27 repos with node-ipc in the graph to a platform override in package.json pinning node-ipc to 9.1.5 or 12.0.0. Merged the platform team's pull requests in cohorts (5 repos per cohort), with a 30-minute observation window between cohorts so an accidental pipeline break would not stop the entire estate at once. Added the override block to the platform workflow template (.github/workflow-templates/node-build.yml) so the pin will apply automatically to future repo creations as well.

Finally the detection stage: activated the Falco rule DNS exfiltration to node-ipc supply chain attacker domain on two cluster platforms running ARC pools. Rolled out the Tetragon policy in a third cluster platform (a tenant-owned platform cluster with a Cilium-Hubble stack). Ran a DNS egress logging audit across all platform build hosts for the 11-hour window — no hits on the lookalike domain, the detection pattern stays in place as a vigilance layer for the next wave.

The structural lesson from this episode does not sit in the lockfile pin, but in the relationship between maintainer identity and mail-domain lifecycle. The atlantis-software.net domain expired on 6 May 2026; six days later an attacker had re-registered the domain and set up mail infrastructure; seven days later the first stealer payload sat in the npm registry. That is the structural class in which the supply-chain layer stands today, after Mini-Shai-Hulud and the Composer token leak: not compromised by malicious code, but through a forgotten domain renewal date as an authentication root. In the last two weeks we have seen three different classes — memory extraction (Mini-Shai-Hulud, 11/12 May), diagnostic output (Composer, 14 May) and now domain lifecycle (node-ipc, 15 May). The number of possible vectors is growing faster than defensive discipline.

In the broader architecture arc the answer is not a single patch, but curated supply-chain discipline as its own platform component. The lockfile pin in the workflow file is the emergency measure. The structural answer is a curated Wolfi line with its own npm mirror, an SBOM generated per build (CycloneDX or SPDX), and a maintainer-identity audit layer. Three disciplines that would not individually have prevented the node-ipc incident but that together reduce the impact surface of a comparable incident to minutes rather than hours.

Conclusion

The node-ipc incident is not a technical showpiece on the attacker's calendar. No new exploit, no zero-day flaw in the registry, no creative technique. What makes the finding operationally serious is the structural weakness in maintainer-identity discipline combined with the DNS egress corridor on typical build hosts. Eleven hours of stealer live-time in the registry, a domain-recovery path as the only authentication root, and a supply-chain frontline that today moves more transitive dependencies than any classical library strategy of the past decade.

The question is not whether the override pin to 9.1.5 is enough. It is enough for the concrete path that node-ipc closed on 14 May. The question is whether your platform runs maintainer-identity discipline as its own component, or whether maintainer identities continue to drift through tenant pipelines as a “module detail”. The structural answer is the first option: a curated Wolfi line, an SBOM per build, a maintainer-identity audit across the top 200 transitive dependencies, and a DNS egress discipline that does not depend on the next Falco hit.