What happened#
Chainguard reported that three malicious versions of node-ipc were published to npm on May 14, 2026. node-ipc is a Node.js inter-process communication package with more than half a million weekly downloads, so even a short-lived compromise can matter.
The reported payload was a credential stealer. According to Chainguard, it executed before normal application logic and attempted to collect secrets from the host running the package. That makes developer machines and CI runners the main risk zones.
The malicious code was injected into the CommonJS entry point. Chainguard says the ESM entry point was clean. That distinction matters because CommonJS remains common across older Node.js projects, build tooling, and CI jobs. A project did not need to call a suspicious function for the malware to matter. If the compromised package version was loaded, the payload could run.
Chainguard says its customers were not affected. Its post attributes that to source-built JavaScript packages, provenance tracking, blocklisting, and an upstream fallback cooldown. That is relevant as a defense model, but it does not reduce the exposure for users who installed the malicious npm artifacts directly through ordinary npm flows.
What the malware targeted#
The reported collection logic was broad. Chainguard says the payload searched more than 90 credential file patterns and also collected environment variables from the running process.
The targeted material included:
- AWS, Azure, and GCP credentials
- SSH keys
- Kubernetes configuration files
- GitHub CLI tokens
- npm tokens
- Terraform state
- CI/CD-related secrets
- AI API keys, including Claude and other AI tooling keys where accessible
That last category is no longer an edge case. AI API keys can expose more than model usage credits. Depending on how teams use AI tools, those keys may sit next to source code, internal prompts, logs, test data, customer context, and agent workflows. If an attacker can use the same key from outside the organization, they may gain access to systems or data paths that were not designed with hostile use in mind.
Chainguard says stolen data was compressed into a gzip TAR archive and exfiltrated through two channels. One used DNS TXT queries to Google DNS at 8.8.8.8, which may bypass local DNS monitoring. The other used HTTPS POST requests to a typosquatted-looking domain: sh.azurestaticprovider.net, which resembles legitimate cloud infrastructure naming.
That combination is worth noting. It is not just grab-and-send malware. It appears designed to work inside developer and build environments where outbound HTTPS is common and DNS visibility may be partial.
Indicators and checks#
Chainguard published the following indicators of compromise in its report:
sh.azurestaticprovider.net78a82d93b4f580835f5823b85a3d9ee1f03a15ee6f0e01b4eac86252a700298196097e0612d9575cb133021017fb1a5c68a03b60f9f3d24ebdc0e628d9034144- injected payload block SHA-256:
b2001dc4e13d0244f96e70258346700109907b90e1d0b09522778829dcd5e4cf - hardcoded auth key in payload:
qZ8pL3vNxR9wKmTyHbVcFgDsJaEoUi
The source material also references a module ID used in exfiltration requests, but the collected text does not preserve the value. Do not infer one.
If you use node-ipc, first check whether your environment installed one of the malicious versions named in the original advisory. The collected source text states that three malicious versions existed, but the version numbers are not preserved in the provided material. Use the Chainguard source, npm metadata, lockfiles, and your package manager cache to confirm the exact versions.
A quick local version check is:
node -e "console.log(require('node-ipc/package.json').version)"
That only shows what is currently installed in the local context. It does not prove that a compromised version was never installed on a CI runner, cache, container layer, or developer machine earlier in the window.
What affected teams should do#
If a malicious version was installed in a developer workstation, CI runner, build container, or production environment, treat that environment as compromised until proven otherwise.
Priority actions:
- Remove the malicious package version and reinstall from a known-good lockfile or pinned version.
- Search package-lock, npm cache, container layers, build logs, and artifact metadata for the affected versions.
- Block or investigate traffic to
sh.azurestaticprovider.net. - Review DNS telemetry for suspicious TXT lookups, especially direct queries to
8.8.8.8from build or developer systems. - Rotate exposed secrets, not only cloud keys.
- Include SSH keys, kubeconfigs, GitHub tokens, npm tokens, Terraform state-derived secrets, and AI API keys in the rotation plan.
- Review AWS CloudTrail, Azure Activity Logs, and GCP Audit Logs for activity after the possible compromise window.
- Rebuild affected artifacts from clean environments.
The hard part is scope. Environment variables are often overstuffed in CI. A single build job can carry cloud deployment credentials, package registry tokens, Git credentials, signing material, and service API keys. If the malware ran in that job, the safe assumption is that all secrets visible to that process may have been exposed.
Why this case matters beyond node-ipc#
The technical pattern is familiar: attackers publish a malicious package artifact and rely on normal dependency installation to run their code. What matters here is the target selection and the artifact/source split.
Chainguard says the malicious versions were pre-packaged tarballs with injected code and no corresponding source commits. That is a recurring npm supply-chain pattern. The public repository may look clean while the registry artifact is not. Teams that only review source repositories can miss the thing they actually install.
This is also another reminder that package compromise impact is not measured only by runtime production deployment. A package that runs in CI can be more damaging than one that runs in a locked-down service. Build environments often hold the keys to cloud accounts, registries, clusters, and release pipelines.
The history of node-ipc adds context, but it should not distort the current facts. In 2022, versions of the package were deliberately sabotaged by its maintainer as a protest action affecting systems in Russia and Belarus. Chainguard references that earlier incident because it raised questions about maintainer trust and supply-chain integrity. The 2026 report describes a different event: malicious versions published with credential-stealing behavior. Do not merge those two stories into one claim about attribution.
What not to overclaim#
The provided source material does not establish who published the malicious versions, how the account or publishing path was compromised, how many users installed them, or whether stolen credentials were successfully used after exfiltration.
It also does not provide the malicious version numbers in the collected text, although Chainguard’s full advisory says there were three. Any operational response should use the original advisory and npm registry data to confirm the exact affected versions before writing detection rules or incident statements.
The practical conclusion is still clear. If your Node.js dependency chain included the malicious node-ipc artifacts, this is a secret-exposure incident, not just a package hygiene issue. The response should start with version confirmation, then move quickly to log review, egress investigation, and credential rotation.