Safeguard
Open Source Security

Protestware and Sabotage: When Maintainers Turn Against T...

Protestware turns trusted maintainers into insider threats. See how node-ipc, colors.js, and left-pad became sabotage vectors, and how Safeguard catches the next one.

Nayan Dey
Security Researcher
7 min read

On March 15, 2022, a developer with commit access to node-ipc — a utility pulled roughly 1.1 million times a week and buried deep in the dependency tree of Vue CLI, one of the most popular frontend tooling projects in the JavaScript ecosystem — pushed versions 10.1.1 and 10.1.2 to npm. Buried inside was a module called peacenotwar. If the package detected a Russian or Belarusian IP address, it overwrote every file it could reach on the machine with a heart emoji, no confirmation, no rollback. There was no CVE yet, no advisory, no warning banner. The maintainer wasn't an attacker who'd stolen credentials — he owned the package outright. This is protestware: sabotage committed by the very people users trust to ship safe code. It turns the software supply chain's biggest asset, maintainer trust, into its biggest liability, and it doesn't trip most of the defenses built for external attackers.

What is protestware, and how is it different from a normal supply chain attack?

Protestware is malicious or destructive code that a package's legitimate, verified maintainer inserts intentionally, usually to make a political, ethical, or economic statement, as opposed to code planted by an outside attacker who compromised an account or slipped a typosquat into a registry. The distinction matters enormously for defense. In the 2018 event-stream/flatmap-stream incident, an unknown actor gained trust from the original maintainer, was handed publish rights, and quietly injected code that targeted the Copay Bitcoin wallet — a classic account-takeover supply chain attack. Protestware skips that step entirely. The person shipping the payload is the same person whose name, GPG key, and reputation have signed every previous release, so signature verification, maintainer-reputation scoring, and "who has publish rights" checks all pass cleanly. The malicious commit looks exactly like every other commit from that author, because it is.

What actually happened with node-ipc and the "peacenotwar" module?

RIAEvangelist (Brandon Nozaki Miller), node-ipc's maintainer, shipped destructive, geolocation-triggered file-wiping code directly into a production package used by millions of installs, and it was live for days before removal. The behavior was tracked as CVE-2022-23812 and rated critical, not because the code exploited a flaw, but because npm's advisory database had no other category for "the maintainer did this on purpose." Because node-ipc sat inside vue-cli-plugin-vuex and other Vue CLI dependencies, teams that had never heard of node-ipc, and had no direct relationship with its author, pulled the compromised versions through a transitive dependency three or four layers deep. GitHub and npm eventually pulled the versions and node-ipc's maintainers published a "safe" version, but by then Snyk, Sonatype, and other supply chain researchers were already using the incident to define an entirely new threat category, since existing vulnerability scanners had nothing to flag: the package had no known CVE, no altered checksums signaling tampering, and a maintainer with a clean history.

Was the colors.js and faker.js incident protestware, too?

Yes, though the motive was economic rather than geopolitical: on January 8, 2022, Marak Squires deliberately broke his own widely-used packages colors.js (roughly 20 million weekly downloads) and faker.js to protest large companies using his free labor without paying for it. He pushed a colors.js update, versioned 1.4.44-liberty-2, that printed an infinite loop of "LIBERTY LIBERTY LIBERTY" gibberish to any console using the library instead of rendering text color, and he deleted the entire faker.js repository outright, wiping a package with millions of downloads from existence. Because colors.js is a transitive dependency of huge swaths of the npm ecosystem — including tools inside Amazon's AWS CDK build chain — the breakage cascaded into CI pipelines that had never directly depended on colors.js and had no idea it existed until their builds started failing. Unlike node-ipc, this incident didn't destroy user data, but it proved the same point from a different angle: a maintainer doesn't need malware to sabotage thousands of downstream projects, just publish access and a grievance.

Do maintainers even need malicious code to sabotage users?

No — sometimes the sabotage is simply removing code that half the internet quietly depends on, as the 2016 left-pad incident showed years before "protestware" was a term anyone used. Azer Koçulu, in a naming dispute with Kik over an unrelated package, unpublished more than 250 of his npm packages in a single act, including left-pad, an 11-line utility that padded strings with characters. Because left-pad was buried in the dependency graphs of Babel, React Native, and thousands of other projects, npm builds across the industry started failing within hours, some pipelines went red before engineers even knew the package existed. npm ultimately restored left-pad manually and changed its unpublish policy so packages with enough downstream dependents can no longer be pulled after 24 hours specifically to prevent a repeat. Left-pad wasn't political and it wasn't destructive code, it was a demonstration that a single maintainer's unilateral decision, made for entirely personal reasons, can sabotage a global build system just by walking away.

How common is protestware, and is it a growing risk?

It's more common than most engineering teams realize, and it clusters around real-world geopolitical flashpoints rather than staying rare or theoretical. Russia's February 2022 invasion of Ukraine alone triggered a wave of npm and PyPI packages modified to display anti-war messages or alter behavior for users with Russian or Belarusian IP addresses, including es5-ext and event-source-polyfill, both of which added geolocation-based postinstall scripts. Most of those were non-destructive protest banners rather than data-wiping code like node-ipc's, but researchers at the time struggled to tell the two categories apart quickly, because both look identical to a scanner: a new version, published by the verified maintainer, with new logic that has nothing to do with the package's stated function. The Open Source Security Foundation and several commercial supply-chain vendors began tracking "maintainer-introduced" incidents as a distinct risk category afterward, precisely because traditional CVE-driven vulnerability management assumes bugs are accidents, and has no workflow for a maintainer who is, on purpose, the threat actor.

How Safeguard Helps

Protestware defeats identity-based trust models by definition, so Safeguard doesn't rely on "is this maintainer verified" as the last line of defense; it treats every dependency version bump as a behavioral event worth inspecting, not just a checksum to validate.

  • Version-diff behavioral analysis flags new releases that introduce filesystem writes, network calls, or geolocation logic that wasn't present in prior versions of the same package, the exact pattern behind node-ipc's peacenotwar payload and the es5-ext postinstall scripts, so a destructive change surfaces before it reaches a build.
  • Dependency pinning and update policy enforcement stops automatic upgrades to packages like colors.js or left-pad from propagating into CI the moment they're published, giving security teams a review window instead of inheriting a maintainer's decision in real time.
  • SBOM-driven blast radius mapping shows instantly which internal services depend, even transitively, on a flagged package like node-ipc or faker.js, so a team that has never heard of a given dependency still knows within minutes whether it's exposed.
  • Maintainer and ownership-change monitoring alerts when publish rights, account control, or npm ownership on a critical dependency shift, since both account-takeover attacks and protestware incidents often follow a change in who can push code.
  • Registry-source verification and mirroring lets teams pin to a vetted, known-good snapshot of a package rather than always resolving to "latest," neutralizing the specific failure mode where a single unilateral push, whether malicious, political, or just personal, breaks every downstream build at once.

Protestware isn't a bug class that will get patched away, it's a trust-model problem baked into how open source distribution works: anyone with publish rights can, at any moment, decide to turn against their own users. Safeguard's approach assumes that possibility is always live and builds detection around behavior and blast radius instead of betting entirely on a maintainer's past reputation.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.