Three Fake npm Versions Just Tried to Steal Your AWS, GCP, Azure—and Your Claude AI Settings

An Account No One Recognized, a Package Almost Everyone Forgot

On the night of May 14, 2026, an npm account no one had heard of pushed three new versions of a package millions of projects had quietly forgotten about. The package was node-ipc. The versions were 9.1.6, 9.2.3, and 12.0.1. The legitimate previous release — 12.0.0 — had shipped 21 months earlier, on August 12, 2024.

The new versions each contained an identical 80 KB blob of obfuscated JavaScript appended to the end of node-ipc.cjs. StepSecurity's AI Package Analyst flagged it within hours. By morning, anyone who had run npm install on a stale CI image or unpinned development environment had handed over more than 90 categories of cloud credentials.

The compromise account was registered to atiertant (a.tiertant@atlantis-software.net). It had never published a release of node-ipc before. The original maintainer, Brandon Nozaki Miller (RIAEvangelist), had nothing to do with this round.

Why node-ipc Is a Target Worth Burning a Brand New Account For

node-ipc is a Node.js inter process communication library. At the height of its usage it pulled over 10 million weekly downloads through transitive dependencies. Vue's CLI tooling famously depended on it during the 2022 sabotage incident, when the original maintainer pushed a payload that wiped files on machines geolocated to Russia and Belarus.

That 2022 attack got node-ipc removed from a lot of dependency trees, but not all of them. Old CI images, vendored package locks, and projects that pinned to a specific Vue major still pull it. The 21 month gap between the legitimate 12.0.0 release and the May 2026 compromise meant any auto upgrade tool — Renovate, Dependabot, npm's own npm outdated — would happily flag the new versions as available updates.

StepSecurity's analysis is blunt about the targeting: "This 2026 attack is independently staged by a different actor with a purely financial credential theft motive." The 2022 incident was ideological vandalism. This one is robbery.

The Payload — and Why It Doesn't Need a Postinstall Hook

Most npm supply chain attacks of the last three years have leaned on lifecycle scripts: a preinstall or postinstall field in package.json that runs at install time and detonates before the developer realizes anything happened. That pattern is loud. Security tools watch for new lifecycle hooks. Package registries flag them. Sophisticated targets have started to install with --ignore-scripts by default.

node-ipc 9.1.6, 9.2.3, and 12.0.1 contain no lifecycle scripts. StepSecurity's analysis: "There are no preinstall, install, or postinstall scripts in package.json."

Instead, the payload is an Immediately Invoked Function Expression (IIFE) appended to the very end of node-ipc.cjs. It detonates the first time any application does require('node-ipc'). The 80 KB blob is dense, obfuscated, and reads as normal looking ESM/CJS interop boilerplate until you trace the control flow.

The execution path matters: --ignore-scripts does not help here. Lockfile hashes do not protect you if you upgrade. The only thing that catches this kind of payload before it runs is a tool that actually executes the package in a sandbox before installation, or one that signature scans the published artifact rather than relying on the manifest.

What It Steals

Once the IIFE detonates, the malicious code walks the filesystem and the environment looking for over 90 categories of credentials. StepSecurity catalogued the harvesting targets:

• Cloud providers: AWS access keys and session tokens, Azure CLI tokens, GCP service account JSON, DigitalOcean API tokens, Hetzner Cloud tokens.
• Source control and CI: SSH keys (~/.ssh/), GitHub CLI configurations, npm authentication tokens (~/.npmrc), GitLab personal access tokens, CircleCI and Jenkins API tokens.
• Container and orchestration: Kubernetes service account tokens and kubeconfig files, Docker registry credentials, Helm repository configurations.
• Infrastructure as code: Terraform state files (which often contain provisioned secrets), Pulumi state, Ansible vault passwords.
• Databases: PostgreSQL .pgpass, MySQL .my.cnf, MongoDB connection strings, Redis auth tokens.
• AI tooling: Claude AI configuration and credential files, Kiro IDE settings.

The last category is what makes this attack genuinely novel. Until May 2026, npm supply chain payloads treated AI assistant credentials as an afterthought. The atiertant payload treats them as a primary target — likely because compromised LLM API keys can be sold, used to mine model output, or used to exfiltrate context from a developer's ongoing conversations with their AI assistant.

Once collected, the credentials are bundled into a staging directory under $TMPDIR/nt-*, then exfiltrated by a daemon process that runs with the environment variable __ntw=1 set. Outbound traffic goes to sh.azurestaticprovider.net (an attacker controlled domain that looks plausibly like Azure infrastructure) and the IP 37.16.75.69.

Why This Becomes an Email Problem the Day After

The 90 category credential list includes the things you would not initially associate with a JavaScript IPC library: SendGrid API keys, Mailgun tokens, Postmark server credentials, Amazon SES IAM keys, and Microsoft 365 application secrets used for outbound mail. Any developer whose machine touched the compromised node-ipc version had those credentials swept up alongside their AWS keys.

That matters because credential theft is almost never the end state. It is a precursor. Attackers who collect mail provider tokens turn them into phishing infrastructure within days — exactly the same playbook we saw in last week's Amazon SES key theft from GitHub repos that fueled mass phishing from victim domains. The IAM key gets stolen on Monday. By Wednesday it is sending phishing email from the victim company's own authenticated domain, signed by their own DKIM key, with their own SPF record vouching for the sending IP. By Friday a third party victim has clicked the link and lost their credentials too.

If your team uses node-ipc 9.1.6, 9.2.3, or 12.0.1 and you do nothing else, rotate your mail provider credentials. SES IAM keys, SendGrid API keys, Mailgun tokens, Postmark server keys, Microsoft Graph mail send application secrets — all of them. Then check your sent folders and outbound mail logs for the last 72 hours for any send patterns you do not recognize.

How to Tell If You're Affected — And What to Do About It

If you have run npm install, npm ci, yarn install, or pnpm install on a project that resolves to node-ipc 9.1.6, 9.2.3, or 12.0.1 between May 14 and May 16, 2026, assume credential exposure.

Detect:

• Check your package-lock.json and yarn.lock for any of the three compromised versions.
• Search your machine for staging directories: ls -la $TMPDIR/nt-* (or /tmp/nt-* on Linux).
• List running processes for any daemon with __ntw=1 in its environment: ps eww | grep __ntw=1.
• Check egress logs for connections to sh.azurestaticprovider.net or 37.16.75.69 since May 14.

Remediate (in order):

• Pin node-ipc to a known good version: 9.2.1 or 12.0.0. Delete node_modules and reinstall.
• Rotate every credential the package can reach. That is the entire 90 category list above, not just cloud provider keys. AWS, GCP, Azure, GitHub, npm, Docker registries, Terraform Cloud, Anthropic API, OpenAI API, SES, SendGrid, Mailgun — rotate them all.
• Revoke active sessions in any service whose tokens may have leaked. GitHub fine grained tokens, AWS STS sessions, GCP service account keys.
• Force re authentication for any CI/CD pipeline that ran the compromised version. Treat existing pipeline secrets as burned.
• Audit git log and audit logs for any activity since May 14 that did not originate from a known human or system identity.

Prevent (going forward):

• Add node-ipc to a deny list in your package management tool. There is no modern project that needs to pull in an unmaintained IPC library for which the last legitimate release was 21 months ago.
• Move CI installs to a hermetic build environment that does not have access to long lived credentials. Use OIDC token exchange and short lived credentials wherever possible.
• Adopt npm provenance attestations and verify them in CI — supply chain provenance is the only credible defense against this attack pattern.

The Pattern Across May 2026

The node-ipc compromise is the third major npm credential theft of May 2026, after the Mini Shai Hulud wave against TanStack, Mistral AI, and 160+ packages on May 12 and the TeamPCP supply chain attacks against Checkmarx, Bitwarden CLI, and Trivy earlier in the month. Three discrete attackers, three discrete attack patterns, one shared insight: developer credentials are the highest leverage target on the modern internet.

A stolen end user password gets you one inbox. A stolen developer credential gets you the inbox, the codebase, the cloud account, the production database, the CI pipeline, the secrets manager, the mail relay, and any AI assistant API key that has been quietly accumulating context. The asymmetry is no longer ignorable.

Why the AI Settings Targeting Matters

The node-ipc payload's targeting of Claude AI and Kiro IDE settings is the part of this attack that deserves the most attention from defenders. Most developer AI assistants store local configuration that includes API keys, recent conversation history caches, and in some cases plaintext context from the user's machine. A stolen Anthropic or OpenAI API key by itself is bad — it can be resold or used to mine the victim's model budget. But a stolen IDE configuration with attached conversation context can leak:

• Source code the developer pasted into a chat
• Internal architectural details described to an assistant during pairing
• Customer data the developer included in a debugging session
• The text of the AI assistant's responses, which may reveal proprietary system internals

The implication for development teams is straightforward: AI assistant credentials need to be rotated and treated as production secrets, not personal preferences. If your engineers are using Claude, Cursor, Kiro, or any other local assistant, those credentials are now a primary supply chain target, not an afterthought.

The Wider Lesson

There is no fix for the structural problem node-ipc exposes. The npm registry will continue to publish whatever a registered account uploads. Auto upgrade tooling will continue to pick up new versions. Most projects will continue to depend on packages whose original maintainers have moved on, leaving accounts dormant and registry positions valuable to anyone willing to take them over.

The defensive posture has to assume compromise. Short lived credentials. Hermetic builds. Provenance attestations. Aggressive deny lists for unmaintained packages. Rotation as a routine operation, not a fire drill.

The next atiertant is already registering an account.