It started as an innocent protest. Npm, JavaScript's package manager maintainer RIAEvangelist, Brandon Nozaki Miller, wrote and published an open-code npm source-code package called peacenotwar. It did little except add a protest message against Russia's invasion of Ukraine. But then, it took a darker turn: It began destroying computers' file systems. 

Ukraine Crisis

• Coding inside a war zone
• How you can help: Donation sites and resources
• Ukrainian police take down phishing gang behind payments scam
• International Refugee Assistance Project partners with Rosetta Stone to aid refugees

To be exact, Miller added code that would delete the file system of any computer with a Russian or Belorussian IP address. Then, its maintainer added the module as a dependency to the extremely popular node-ipc mode. Node-ipc, in turn, is a popular dependency that many JavaScript programmers use. And it went from annoying to a system destroyer. 

The code has undergone several changes since it first appeared, but it must be regarded as highly dangerous. Underlining its potential for damage, Miller encoded his code changes in base-64 to make it harder to spot the problem by simply reading the code. 

According to developer security company Snyk, which uncovered the problem, "node-ipc (versions >=10.1.1 <10.1.3) is a malicious package. This package contains malicious code that targets users with IP located in Russia or Belarus, and overwrites their files with a heart emoji." It's now being tracked as CVE-2022-23812. Synk gives this corrupted open-was able to source package a critical Common Vulnerability Scoring System (CVSS) rating of 9.8, critical. 

In other words, you simply shouldn't use it at all. Period.

That's easier said than done. Node-ipc is present in many programs. This nodejs module is used for local and remote InterProcess Communication (IPC) on Linux, Mac, and Windows systems. It's also used in the very popular vue-cli, a Javascript framework for building web-based user interfaces. From there, this malware wrecked a large number of systems. 

Liran Tal, the Snyk researcher who uncovered the problem said, "Even if the deliberate and dangerous act of maintainer RIAEvangelist will be perceived by some as a legitimate act of protest, how does that reflect on the maintainer's future reputation and stake in the developer community?" Would this maintainer ever be trusted again to not follow up on future acts in such or even more aggressive actions for any projects they participate in?"

Miller himself defended his peacenotwar module on GitHub, saying "This is all public, documented, licensed and open source." 

But, what if someone did this and didn't leave such a message? And, if letting users make an informed decision mattered, why was the dangerous code obscured? 

In any case, as we all know, people are lousy at reading documentation. Besides, as Sophos Senior Threat Researcher. Sean Gallagher, tweeted, anyone who just added code willy-nilly to their production systems is asking for trouble. "If you are live patching dependencies you have no QA controls for, you are not doing SecOps at all."

But all that said, this "protestware" sets a dangerous precedent. As one programmer on GitHub wrote, "What's going to happen with this is that security teams in Western corporations that have absolutely nothing to do with Russia or politics are going to start seeing free and open-source software as an avenue for supply chain attacks (which this totally is) and simply start banning free and open-source software -- all free and open-source software -- within their companies. Or at least all of it which is community maintained. This will have no positive effect for Ukrainians, you idiot, and will only hurt FOSS [Free and open-source software] adoption." Exactly so. 

In the meantime, in open-source's usual fixing its own messes ways, another developer Tyler S. Resch, MidSpike, has started an effort to build a safe node-ipc fork on GitHub. 

Related Stories:

• Malware authors target rivals with malicious npm packages
• When open-source developers go bad
• Securing the open-source ecosystem: SBOMs are no longer optional