This week, the JavaScript ecosystem was hit by something I’ve never seen in my three decades of software development: a popular open source maintainer deliberately weaponizing their own package. The node-ipc library — downloaded over a million times per week and a transitive dependency of major tools like Vue CLI — was found to contain malicious code targeting users with Russian and Belarusian IP addresses.
The maintainer, RIAEvangelist, pushed updates that would overwrite files with heart emojis on systems geolocated to Russia or Belarus, in protest against the ongoing invasion of Ukraine. While the political sentiment may be understandable, the implications for software supply chain security are deeply troubling.
What Actually Happened#
The timeline is worth examining carefully. On March 7, version 11.0.0 of node-ipc was published with code that checked the user’s external IP address against geoIP databases. If the system was located in Russia or Belarus, the code would recursively traverse the filesystem and replace file contents with a heart emoji (❤️). Later versions toned this down to simply creating a file called WITH-LOVE-FROM-AMERICA.txt on the desktop.
The malicious code was obfuscated using base64 encoding — a deliberate attempt to hide the payload from casual code review. Versions 10.1.1 and 10.1.2 were also affected, which is particularly dangerous because they sit within a semver range that many projects would auto-update to.
The Snyk advisory classified this as CVE-2022-23812, and it was quickly flagged across the ecosystem. But the damage window was real — anyone running npm install or npm update on affected projects during that period could have pulled in destructive code.
The Supply Chain Trust Problem#
I’ve written about npm supply chain issues before, and every time I think we’ve hit peak concern, something new comes along. The event-stream incident in 2018 involved a malicious actor taking over an abandoned package. The ua-parser-js hijacking last year was a compromised maintainer account. But this? This is the actual maintainer deliberately inserting destructive code into their own widely-used package.
That’s a fundamentally different threat model. We’ve built our entire dependency ecosystem on the assumption that maintainers act in good faith. Package signing, two-factor authentication, provenance tracking — none of these help when the threat actor has legitimate commit access and is the recognized owner of the package.
The Vue CLI team had to scramble to pin their node-ipc dependency to a safe version. Any project using node-ipc transitively — and there are thousands — was potentially affected. This is the tyranny of deep dependency trees that the Node.js ecosystem has always struggled with.
What Can We Actually Do?#
The knee-jerk reaction is to call for more vetting of open source maintainers, but that misses the point. You can’t pre-screen someone’s future political motivations or emotional state. The real solutions are structural:
Lock your dependencies. If you’re not using lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) and committing them to version control, you’re playing Russian roulette with every install. Lockfiles won’t protect you from a compromised initial install, but they prevent silent updates from pulling in new malicious versions.
Use npm audit and automated scanning. Tools like Snyk, Socket, and npm’s built-in audit can flag known vulnerabilities, including this one once it was cataloged. The gap between publication and detection is the danger zone.
Minimize your dependency tree. I know this sounds like the old “just write it yourself” argument, but it’s more nuanced than that. Do you really need a library for something your platform provides natively? The Node.js standard library has grown significantly — node:fs, node:crypto, node:http2 are all mature. Every dependency you don’t take is one less trust decision.
Consider dependency review workflows. GitHub’s dependency review action can flag new dependencies in pull requests. It won’t catch everything, but it adds a human checkpoint before new packages enter your supply chain.
The Ethics Question Nobody Wants to Discuss#
There’s a broader conversation happening in the open source community right now about whether it’s acceptable to use your software as a form of protest or sanction. The Open Source Initiative has been clear that open source licenses are, by definition, non-discriminatory — they can’t restrict usage by geography, purpose, or person.
But licenses and ethics aren’t the same thing. Some developers are arguing that maintainers have the right — maybe even the obligation — to use whatever leverage they have against what they see as injustice. Others, myself included, worry about the precedent. If we accept supply chain sabotage as legitimate protest, we’ve opened a door that can’t be closed. Who decides which causes justify weaponizing code? What happens when someone with a less universally sympathized-with cause does the same thing?
My Take#
I have enormous sympathy for anyone affected by the war in Ukraine, and I understand the impulse to use whatever tools you have at your disposal. But as someone who has spent decades building systems that depend on trust in the software supply chain, I can’t endorse this approach.
The node-ipc incident didn’t just affect Russian systems — it affected the trust model of the entire npm ecosystem. It gave every CISO and procurement officer another reason to be wary of open source dependencies. And it made the already thankless job of open source maintenance even harder for everyone else.
What I want to see come out of this is not more finger-pointing, but better tooling. We need reproducible builds, better provenance tracking, and runtime sandboxing for dependencies. Deno’s permission model is looking more prescient by the day — imagine if node-ipc had to explicitly request filesystem write access.
The open source ecosystem is one of the great achievements of our industry. Let’s not let it become a battlefield.