On January 8, 2022, thousands of developers woke up to broken builds. Applications that had worked perfectly the night before were now printing gibberish — an infinite loop of the word "LIBERTY" followed by non-ASCII characters. The cause was not a bug. It was an act of protest by Marak Squires, the sole maintainer of colors.js and faker.js, two of the most depended-upon packages in the entire npm ecosystem.
The Incident
Marak pushed version 1.4.44-liberty-2 of colors.js to npm. This version replaced the package's core functionality with an infinite loop that printed garbage text to the console, effectively bricking any application that imported it. Simultaneously, he wiped the faker.js repository on GitHub, replacing its README with "What really happened with Aaron Swartz?"
The colors.js package had over 22 million weekly downloads at the time. faker.js had over 2.8 million. Together, they were dependencies (direct or transitive) of tens of thousands of projects, including major tools like AWS CDK.
// The sabotage code added to colors.js
let am = require('../lib/custom/american');
am();
am();
// This function contained an infinite loop printing "LIBERTY LIBERTY LIBERTY..."
Within hours, GitHub suspended Marak's account. npm reverted the malicious versions. But the damage — broken CI pipelines, failed deployments, hours of wasted developer time — was done.
The Backstory
This did not come out of nowhere. Marak had been publicly frustrated for months. In November 2020, he posted an issue on the faker.js GitHub repository titled: "No more free work from Marak — Pay Me or Fork This." He argued that Fortune 500 companies were profiting from his unpaid labor while he struggled financially.
He was not wrong about the economics. Open source maintainers frequently carry the weight of critical infrastructure on their shoulders with little or no compensation. The colors.js package was a dependency of Amazon's AWS CDK, and yet Marak saw none of that value returned to him.
But his method of protest — deliberately breaking production software relied upon by millions — crossed a line that the community could not ignore.
The Deeper Problem
The colors.js/faker.js incident is a symptom of a structural problem in how we consume open source software:
Single Points of Failure
Both packages were maintained by a single person. There was no governance structure, no co-maintainers with publish access, no organizational backing. When that single person decided to act destructively, there was no check or balance.
This is shockingly common in the npm ecosystem. A 2021 study found that over 50% of npm packages with more than 1,000 weekly downloads had only a single maintainer.
The Entitlement Gap
Companies build billion-dollar products on top of free open source libraries. Many of these companies have never contributed a single dollar, bug report, or pull request back to the projects they depend on. This creates a sustainability crisis that eventually manifests as burnout, abandonment, or — in extreme cases — sabotage.
Inadequate Version Controls
Many projects that were affected had configured their dependencies to automatically accept minor and patch updates (using ^ or ~ ranges in package.json). This meant the sabotaged version was pulled in automatically, without any human review.
{
"dependencies": {
"colors": "^1.4.0" // Automatically accepts 1.4.44-liberty-2
}
}
Community Response
The community response was swift but divided. The faker.js project was forked as @faker-js/faker by a group of community maintainers who established proper governance, multiple maintainers, and a sustainable development model. This fork quickly surpassed the original in downloads and has become the de facto standard.
npm implemented additional safeguards against maintainer-initiated sabotage, though the specifics of these measures remain somewhat opaque.
The incident also accelerated conversations about funding open source. GitHub Sponsors, Open Collective, and Tidelift all saw increased attention, though the fundamental economics of open source maintenance remain largely unchanged.
Practical Takeaways
Pin Your Dependencies
Stop using semver ranges for production dependencies. Use exact versions and lockfiles. Update deliberately, not automatically.
{
"dependencies": {
"colors": "1.4.0" // Exact version, not ^1.4.0
}
}
Audit Maintainer Health
Before depending on a package, look at:
- How many maintainers does it have?
- Is there organizational backing?
- Has the maintainer expressed burnout or frustration?
- What is the bus factor?
Contribute Back
If your organization depends on open source software, contribute to its sustainability. This is not charity — it is risk mitigation. A well-funded, well-maintained dependency is a secure dependency.
Build Internal Registries
Mirror critical dependencies in an internal registry (Artifactory, Verdaccio, etc.). This gives you a buffer against upstream changes and allows you to vet updates before they reach your developers.
Maintain a Current SBOM
When a dependency is compromised, the first question is always: "Where are we using this?" An up-to-date SBOM answers that question instantly.
How Safeguard.sh Helps
Safeguard.sh continuously monitors your dependency tree for risk signals — not just known CVEs, but also maintainer activity patterns, package health metrics, and sudden behavioral changes. When a package like colors.js is compromised, our platform immediately identifies every application in your portfolio that depends on it, directly or transitively.
Our SBOM management capabilities ensure you always have a current, accurate inventory of every component in your software. Combined with policy gates that can block unvetted dependency updates from reaching production, Safeguard.sh turns reactive scrambling into proactive defense.