On March 15, 2022, thousands of developers running npm install unknowingly pulled malicious code into their projects. The maintainer of node-ipc—a widely-used inter-process communication library—introduced a protestware module called peacenotwar that corrupted files on machines geolocated to Russia and Belarus. This wasn't a nation-state attack or a cryptocurrency miner. It was intentional sabotage by a trusted open-source maintainer protesting the invasion of Ukraine.
If your team uses Vue.js or any of the hundreds of packages that depend on node-ipc, you were exposed. This incident reveals how transitive dependencies create blind spots in your supply chain—and how quickly maintainer trust can become a liability.
Timeline of Events
March 15, 2022: The maintainer released node-ipc versions containing the peacenotwar module. The code checked the user's IP geolocation and, if matched to Russia or Belarus, overwrote files with heart emoji characters.
March 16, 2022: Developers began reporting corrupted files and unexpected behavior. The issue spread through Vue.js projects due to vue-cli depending on node-ipc.
March 16, 2022 (later): Snyk published CVE-2022-23812 and SNYK-JS-PEACENOTWAR-2426724, formally documenting the vulnerabilities.
March 17-18, 2022: Package maintainers across the ecosystem scrambled to pin versions and warn users. The damage had already propagated through automated dependency updates.
Which Controls Failed
Dependency vetting: Most teams had no process to review transitive dependencies. Node-ipc sat several layers deep in the dependency tree—pulled in by vue-cli-service, which was pulled in by @vue/cli-service, which your developers installed without examining what came along for the ride.
Change monitoring: Teams running automated dependency updates had no alert when node-ipc introduced a new module (peacenotwar) or when the package behavior changed. The malicious code executed during installation via preinstall and postinstall hooks, but no monitoring caught the file system writes.
Geolocation-based execution: The attack used IP-based geolocation to target specific regions. Standard sandbox testing in CI/CD wouldn't have caught this unless your test infrastructure happened to route through affected IP ranges.
Version pinning: Projects using caret (^) or tilde (~) version ranges automatically pulled the malicious update. Even teams following frequent update guidance were vulnerable because the attack window was less than 48 hours.
What Standards Require
The NIST Cybersecurity Framework (CSF) v2.0 addresses this under the Supply Chain Risk Management (SR) category. Function ID.SC-3 requires you to "manage cybersecurity risks arising from suppliers and third-party partners." That includes understanding your transitive dependency graph and having mechanisms to detect malicious changes.
ISO/IEC 27001:2022 covers this in Annex A.15 (Supplier relationships). Control A.15.1.1 requires "information security policy for supplier relationships" and A.15.1.2 mandates "addressing security within supplier agreements." For open-source dependencies, this means defining acceptable risk levels and monitoring procedures.
PCI DSS v4.0.1 Requirement 6.3.2 states that "software development personnel receive training on secure coding techniques." Part of secure coding is understanding dependency risk. Requirement 6.2.4 requires you to address "bespoke and custom software vulnerabilities"—which includes vulnerabilities introduced through your dependency chain, whether you wrote the code or not.
NIST SP 800-53 Rev 5 provides more specific guidance. Control SA-12 (Supply Chain Protection) requires you to "employ anti-counterfeit technologies and processes" and "limit harm from potential adversaries." Control SR-3 (Supply Chain Controls and Processes) explicitly calls out the need to "assess supply chain-related risks."
None of these standards say "trust npm packages because they're popular." They all require you to know what's in your supply chain and have detection mechanisms for malicious changes.
Lessons and Action Items
Map your transitive dependencies: Run npm ls or yarn why to see the full dependency tree for critical applications. You need to know that node-ipc is three levels deep in your Vue.js stack. Tools like npm-audit or Snyk can generate dependency graphs, but you need to actually review them—not just run the scan and file the report.
Implement Software Bill of Materials (SBOM) generation: Generate an SBOM for every production build using tools like CycloneDX or SPDX. Store these with your release artifacts. When an incident like node-ipc happens, you need to answer "are we affected?" in minutes, not days. Your SBOM should include transitive dependencies, not just direct ones.
Lock dependency versions in production: Use package-lock.json or yarn.lock and commit them to version control. Don't use caret or tilde ranges for production deployments. When you update dependencies, do it deliberately in a PR where you can review the changes—not automatically via Dependabot without human review.
Monitor package behavior changes: Configure tools like Socket or Snyk to alert on new dependencies, new maintainers, or behavioral changes like new install scripts. The peacenotwar module appeared as a new dependency—that should have triggered an alert before it reached production.
Sandbox dependency installation: Run npm install in an isolated environment before deploying to production. Monitor file system writes, network calls, and process spawns during installation. If a package writes to unexpected locations (like node-ipc overwriting files), block the deployment.
Review install scripts: Audit any package using preinstall, postinstall, or preuninstall hooks. These scripts run with your user's permissions and can do anything. Consider using --ignore-scripts for installation and only enabling scripts for packages you've explicitly reviewed.
Establish maintainer trust criteria: For critical dependencies, document who maintains them, how long they've been maintained, and whether they have organizational backing. A solo maintainer with commit access to packages used by millions of projects is a concentration risk. Consider contributing to or sponsoring projects you depend on—it gives you visibility and sometimes influence over project direction.
Have a rollback procedure: When node-ipc was compromised, teams needed to immediately roll back to known-good versions. Your deployment process should support instant rollback to the previous dependency snapshot. Test this procedure quarterly—not during an incident.
The node-ipc incident wasn't sophisticated. It was a maintainer with commit access making an ideological decision. Your supply chain security doesn't just protect against nation-state attackers—it protects against anyone with access to a package you depend on, for any reason. That's why standards require you to treat dependencies as untrusted suppliers, not assumed-safe infrastructure.
