On March 15, 2022, the open source community was rocked by a discovery that challenged fundamental assumptions about trust in the software supply chain. Brandon Nozaki Miller, known as RIAEvangelist, deliberately introduced malicious code into his widely-used node-ipc npm package. The code targeted systems geolocated to Russia and Belarus, overwriting files with a heart emoji. This was not a hack. This was the maintainer himself turning his own package into a weapon.
What Happened
The node-ipc package is a popular inter-process communication library for Node.js, downloaded over a million times per week. It serves as a dependency for major projects including Vue.js CLI tooling.
In versions 10.1.1 and 10.1.2, Miller introduced code that checked the external IP address of the machine running the package. If the IP geolocated to Russia or Belarus, the code would attempt to overwrite the contents of all files on the system with a heart emoji (❤️). A separate dependency, peacenotwar, was also added — this one created text files on the desktop with anti-war messages.
The destructive payload was obfuscated using base64 encoding, making it non-obvious during casual code review:
// Simplified representation of the destructive logic
const geo = await fetchGeo(externalIP);
if (geo.country === 'RU' || geo.country === 'BY') {
// Recursively overwrite all accessible files
files.forEach(file => fs.writeFileSync(file, '❤️'));
}
Version 10.1.3 removed the destructive file-wiping code but retained the peacenotwar dependency. Later versions (11.0.0+) continued to include the protest messaging module.
The Blast Radius
The impact was immediate and far-reaching:
- Vue.js CLI depended on
node-ipc, meaning any developer creating or building Vue projects pulled in the compromised code - Unity Hub and other Electron-based applications were affected
- Developers in Russia and Belarus reported data loss from the file-wiping payload
- The incident was tracked as CVE-2022-23812 with a CVSS score of 9.8 (Critical)
Snyk researchers were among the first to publicly document the issue, and the npm registry flagged the affected versions. But the damage — both technical and to community trust — was already done.
Why This Matters Beyond the Incident
This was not a typical supply chain attack. There was no external attacker. No compromised credentials. No typosquatting. The legitimate, verified maintainer of a popular package made a deliberate decision to weaponize it.
This raised uncomfortable questions that the open source community is still grappling with:
Trust is the foundation of open source. Every time you run npm install, you are trusting thousands of maintainers — most of whom you have never met — to not do something malicious. The node-ipc incident proved that this trust can be violated by anyone, at any time, for any reason.
Motivations are irrelevant to the blast radius. Whether you agree with Miller's political stance is beside the point. The technical reality is that production systems were compromised. Files were destroyed. The mechanism — a maintainer abusing their publish access — is identical regardless of the motivation behind it.
Version pinning is not enough. Many teams that pinned to node-ipc@10.1.0 were safe from the destructive payload. But transitive dependency updates through vue-cli and other packages could still pull in compromised versions if lockfiles were regenerated.
The "Protestware" Precedent
The node-ipc incident coined the term "protestware" and opened a Pandora's box. In the weeks that followed, multiple other packages introduced protest-related code — some benign (displaying messages), others more destructive.
This created a new threat category that traditional security scanning was not designed to detect. The code was not "malicious" in the traditional sense — it came from a legitimate source, was published through legitimate channels, and performed actions that were technically within the maintainer's rights as the package owner.
Defensive Lessons
Organizations need to rethink their dependency management strategies in light of this incident:
1. Lock Everything Down
Use lockfiles (package-lock.json, yarn.lock) religiously and audit changes to them in code review. Any modification to a lockfile should be treated as a potential security event.
2. Monitor Maintainer Behavior
Track unusual patterns in your dependency tree: sudden version bumps, new dependencies added without clear purpose, changes in publishing frequency. These can be early indicators of compromised or weaponized packages.
3. Use SBOMs for Visibility
You cannot protect what you cannot see. A current Software Bill of Materials (SBOM) for every application gives you the ability to quickly answer: "Are we affected?" when the next supply chain incident drops.
4. Implement Dependency Review Gates
Before any dependency update reaches production, it should pass through automated security scanning that checks for:
- Known vulnerabilities (CVE databases)
- Behavioral anomalies (new network calls, filesystem access)
- Reputation changes (maintainer activity, community sentiment)
5. Have an Incident Response Plan for Dependencies
When a supply chain compromise is announced, how quickly can your team:
- Identify all affected applications?
- Roll back to safe versions?
- Validate that no damage occurred?
If you do not have clear answers to these questions, you are not prepared.
How Safeguard.sh Helps
Safeguard.sh provides continuous monitoring of your software supply chain, including real-time detection of compromised packages. Our platform generates and maintains SBOMs for all your applications, giving you instant visibility into whether a newly-discovered threat like the node-ipc protestware affects your organization.
When the next supply chain incident drops — and it will — Safeguard.sh ensures you can answer "are we affected?" in seconds, not days. Our dependency analysis tracks not just direct dependencies but the full transitive tree, identifying risks before they reach your production environment.