node-ipc npm backdoor
How Automic Vault would have prevented the node-ipc npm backdoor.
The node-ipc incident shows why install-script policy is not enough. The malicious code ran from the CommonJS entrypoint when the package was loaded. Automic Vault would have prevented the loaded library from finding useful local secrets to exfiltrate.
Published May 15, 2026
Automic Vault would have prevented the damaging local phase of this incident: the moment malicious package or extension code tried to read workstation secrets, use credential-bearing tools, or install persistence as the developer.
Incident Facts
local execution- Date
- May 14, 2026
- Trigger
- node-ipc 9.1.6, 9.2.3, and 12.0.1 contained a backdoored CommonJS entrypoint.
- Local targets
- Environment variables, npm and GitHub credentials, cloud CLI state, SSH keys, kubeconfig, desktop key stores, browser key databases, and app tokens.
- Follow-on behavior
- Detached child process, temporary archive staging, and DNS TXT exfiltration through attacker-controlled resolver infrastructure.
What Happened?
incident recordDatadog reported that three node-ipc releases published on May 14, 2026 contained the same malicious node-ipc.cjs file. The payload was not an npm lifecycle script. It lived in the CommonJS module path, so it could activate when application or test code required the package.
The malware forked a detached child process, staged collected files into a temporary archive, compressed the result, and sent it out over DNS. That design matters because many organizations focus on HTTP exfiltration while allowing DNS traffic by default.
The target list was broad and local: npm files, GitHub CLI state, Git credential files, AWS/Azure/GCP credentials, SSH keys, Kubernetes config, environment variables, and desktop token stores. The package acted like a local credential collector, not just a malicious dependency.
What Actually Failed?
root causeThis incident defeats a narrow defense that only disables npm preinstall and postinstall scripts. The payload activated at runtime, after dependency installation was over. Any policy that assumes library code is safe once installed misses this class of attack.
The deeper problem is that application dependencies usually run with the same filesystem view as the developer. A utility library should not be able to read cloud credentials and desktop key stores merely because the process required a module.
Where Automic Vault Would Have Stopped It
preventionRuntime access would be constrained
Automic Vault containment and package boundaries are aimed at the execution layer, not only installation. A loaded dependency should not receive arbitrary access to home-directory secret stores.
Secrets would be brokered, not scraped
Tools that need credentials can receive approved, scoped values. A library backdoor that scans ~/.aws, ~/.config/gh, .npmrc, or SSH material would find far less useful data.
Suspicious process behavior would become reviewable
Detached child processes, archive staging, and secret-bearing command use are meaningful risk boundaries. Automic Vault makes those local execution decisions visible instead of treating them as normal library behavior.
Why This Is Prevention, Not Just Detection
local boundaryAutomic Vault would have prevented the useful theft, even though the malicious package could still be present in node_modules. The key is that presence is not authority.
In a protected setup, the node-ipc payload can try to fork and enumerate files, but the credentials it wants are no longer freely readable files. It can try to exfiltrate, but the archive lacks the local secret material that made the campaign valuable.
That is the practical prevention line for runtime backdoors: deny ambient credential access before detection has to be perfect.
Automic Vault does not claim to make npm, PyPI, GitHub Actions, or extension marketplaces impossible to compromise. The prevention claim is narrower and more useful: compromised tools should not inherit every credential and sensitive path on a developer machine.