The Maintainer Who Said Enough
In early January 2022, Marak Squires — the maintainer of two widely-used npm packages, colors (20 million weekly downloads) and faker (2.8 million weekly downloads) — deliberately sabotaged his own packages. He pushed updates that introduced infinite loops printing garbled text to the console, breaking thousands of dependent applications.
The incident exposed a tension that the open source community has struggled with for years: the mismatch between the enormous value that popular packages provide and the minimal support their maintainers receive. But it also raised critical questions about the trust model that underpins the entire npm ecosystem.
While this incident occurred in January 2022, the dynamics that led to it were building throughout 2021 — and the lessons apply to every organization that depends on open source software.
What Happened
Squires published version 6.6.6 of colors and version 6.6.6 of faker.js (the version number itself a signal of his intent). The new versions of colors included code that caused an infinite loop, printing the text "LIBERTY LIBERTY LIBERTY" followed by garbled characters to the terminal.
Any application that imported colors at the affected version would hang or crash when the library was loaded. Because colors was a dependency of thousands of packages — including popular tools like aws-cdk — the blast radius was immediate and massive.
For faker, Squires replaced the entire codebase with a README that said "What really happened with Aaron Swartz?" — a reference to the internet activist who died in 2013. The library simply stopped working.
The Backstory
Squires had been vocal about his frustration for months. In November 2020, he posted on GitHub:
"I am no longer going to support Fortune 500s (and other smaller-sized companies) with my free work. There isn't much else to say. Take this as an opportunity to send me a six-figure yearly contract or fork the project and have someone else work on it."
He pointed out that faker was used by companies generating billions in revenue, yet he received almost nothing for maintaining it. The package had over 2.8 million weekly downloads. The maintenance burden — issues, pull requests, security reports, compatibility updates — was substantial. The compensation was negligible.
The frustration was understandable. The response was destructive.
The Immediate Fallout
- npm reverted the sabotaged versions within hours, restoring previous working versions
- npm locked Squires' account, preventing further publishes
- The
fakercommunity forked the project as@faker-js/faker, which is now maintained by a community team - GitHub suspended Squires' account, though it was later restored
- Thousands of CI/CD pipelines broke overnight as applications pulled the sabotaged versions
Projects using lockfiles were largely unaffected — the lockfile pinned them to the previous working version. Projects that resolved to latest or used loose version ranges pulled the broken versions automatically.
The Deeper Questions
Who Controls Open Source Packages?
When Squires sabotaged his packages, he was exercising control over code he created and maintained. The license (MIT) doesn't guarantee continued maintenance or functionality. Yet millions of developers and thousands of businesses depended on his code. This creates an implicit social contract that has no legal enforcement.
npm's response — reverting versions and locking the account — asserted that the registry has authority over published packages, even against the will of the original author. This is a necessary practical measure, but it raises governance questions about the relationship between maintainers and registries.
Is This a Supply Chain Attack?
Technically, yes. A trusted package was modified to behave maliciously. The attack vector was the same as ua-parser-js — a change published through the normal update mechanism. The difference is intent: this was protest, not criminal exploitation.
But from a technical defense perspective, the distinction doesn't matter. Your monitoring, lockfiles, and update controls should catch this regardless of whether the cause is a disgruntled maintainer, a compromised account, or a nation-state actor.
The Sustainability Crisis Is Real
Squires' frustration resonates with thousands of open source maintainers. The economics are genuinely broken. Companies extract enormous value from open source while contributing little to its maintenance. The result is burned-out maintainers, abandoned projects, and — occasionally — sabotage.
This isn't just a moral issue. It's a security issue. Unmaintained packages don't get security patches. Burned-out maintainers make mistakes. Abandoned accounts get compromised. The sustainability crisis is a supply chain risk factor.
Defensive Measures
1. Use Lockfiles — Always
If every project had used lockfiles with integrity verification, the colors/faker sabotage would have had zero impact. The sabotaged versions would never have been installed because lockfiles pin exact versions and checksums.
This is the single most effective defense against unexpected package changes, whether from sabotage, compromise, or ordinary breaking changes.
2. Evaluate Maintainer Risk
Before depending on a package, consider:
- How many maintainers does it have? A single maintainer is a single point of failure.
- How active is maintenance? Long periods without commits may indicate abandonment.
- Is there organizational backing? Packages maintained by a company or foundation are generally more resilient.
- Are there recent signs of frustration or burnout in issue discussions?
3. Pin Dependencies Conservatively
Use exact version pinning in production dependencies. Avoid ^ and ~ ranges that automatically accept new minor or patch versions. Update dependencies deliberately, with testing, not automatically.
4. Monitor for Behavioral Changes
Tools that detect unexpected changes in package size, dependencies, install scripts, or exports can catch sabotage before it reaches production. A package that suddenly adds an infinite loop or removes all its code should trigger an alert.
5. Support Your Dependencies
This is the long-term fix. If your business depends on open source packages, invest in their maintenance. GitHub Sponsors, Tidelift, Open Collective, and direct contributions all help. It's cheaper than the incident response when a maintainer snaps.
How Safeguard.sh Helps
Safeguard.sh monitors your dependency tree for unexpected behavioral changes, including sudden version jumps, removed functionality, added install scripts, and significant code changes. When a package like colors or faker undergoes a suspicious update, the platform flags it before the update reaches your production builds.
The platform also provides dependency health metrics that include maintainer activity, contributor count, and project governance indicators. These metrics help you identify single-maintainer dependencies that represent elevated risk — before an incident occurs.
Beyond detection, Safeguard.sh enforces version pinning and lockfile integrity policies across your organization. By ensuring that every project uses lockfiles with checksum verification, the platform prevents sabotaged or compromised package versions from propagating through your build pipeline — turning what could be a crisis into a non-event.