Supply Chain Alert: Malicious node-ipc Versions Exfiltrating Dev Secrets

We're seeing this hit some dev environments already. The malicious versions start a socket connection and exfiltrate data. Beyond just checking the lockfile, you should check your SBOMs against the CPEs if you have an automated pipeline. We use Syft and Grype to catch this stuff at build time before it hits production.

Good post. If you are using Kubernetes, make sure to rebuild your images from scratch rather than just redeploying. If your base image or build cache has the malicious layer, you might still be running the bad code even after updating your source code repository.

Great heads up. For those unsure if they pulled these versions locally, you can quickly scan your project directories. If you're using npm, running this command checks if your lockfile resolves to any of the bad versions:

grep -E '"node-ipc":.*"(9\.1\.6|9\.2\.3|12\.0\.1)"' package-lock.


If anything pops up, nuke your `node_modules` folder, audit your exposed secrets immediately, and rotate any credentials stored locally. It's also a good time to double-check your CI/CD pipeline logs for any unusual outbound network activity during builds.

Solid advice. From an IAM perspective, remediation shouldn't stop at rebuilding. If you executed these versions, assume your developer secrets are compromised. Immediately rotate any exposed AWS keys or SSH identities. To verify if credentials were used post-infection, check your CloudTrail logs:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=$USER --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)

Better safe than sorry with identity theft.

Solid advice, Yuki. To complement the lockfile checks, you should verify what's actually sitting in your node_modules directory, as cache issues can sometimes keep malicious versions around even after updating the lockfile. This quick grep helps confirm if the specific bad versions are installed locally:

grep -R '"version"' node_modules/node-ipc/package. | grep -E '9.1.6|9.2.3|12.0.1'


If found, run `npm ci` (or `yarn install --force`) to reinstall clean copies from a trusted registry.

Excellent insights, especially on the IAM side. To help with the forensic timeline, you can check your git history to see exactly when these versions were introduced. This command isolates the relevant changes in your lockfile:

git log -p --all -- package-lock. | grep -B 5 -A 5 "node-ipc"

Knowing the window of exposure helps correlate with any anomalous outbound traffic logs during that period.

Good catch on the cache issues, Dylan. Beyond static file checks, verify runtime behavior on your build agents. Since this malware initiates socket connections, you should audit for suspicious outbound traffic immediately. A quick way to check active connections is:

ss -tulwn | grep node

Identifying the destination IP of these connections can help determine if your secrets were already transmitted before you started the rotation process.