The numerous organizations with projects that depend on popular npm open source libraries “colors.js” and “faker.js” were in for quite the unfortunate surprise over the weekend. According to a report from Bleeping Computer, the developer behind those libraries, Marak Squires, intentionally sabotaged both of the popular packages, causing them to essentially stop working.

(This “inside job” nature of this incident is in contrast to a number of recent high-profile incidents involving open source libraries, such as the Log4J vulnerability and occurrence of embedded malware in npm packages rc, coa, and ua-parser.)

Squires’ actions have had a significant and widespread impact. “Colors,” which enables users to “get color and style in your node.js console.” is downloaded over 23 million times per week and lists nearly 19,000 dependent projects. “Faker,” which produces fake — but realistic and organized – data for testing purposes, is downloaded over 2.4 million times per week and lists over 2,500 dependent projects

Both programs are covered by the MIT open source software license.

RELATED: Log4J "Log4Shell" Zero-Day Vulnerability: Impact and Fixes

What Happened to ‘Colors’ and ‘Faker’?

Squires corrupted the npm library “colors” by adding an infinite loop that essentially generates gibberish code to a user’s terminal in perpetuity.

The corrupted "colors" library.

In the case of "faker," Squires published a corrupted version (6.6.6) to GitHub and npm.

The developer was apparently motivated by frustration over the level of support corporations provide to the open source community. As discovered by Bleeping Computer, Squires posted the following to GitHub in November, 2020.

“Respectfully, 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.”

It is worth noting that “faker” and “colors” are only two of Squires’ numerous open source projects, so we may see additional disruption in the days and weeks ahead. (However, per Squires’ Jan. 6 Twitter post, GitHub has suspended his access to all public and private projects.)

How to Fix Issues with ‘Colors’ and ‘Faker’

Determining whether your applications are impacted by the issues with “colors” and “faker” should be a relatively straightforward exercise. If you are exposed, your application will essentially stop working and you’ll see the aforementioned gibberish code in your console.

For issues with “colors”: As of the evening of January 10, a new issue was opened in the GitHub colors.js repo indicating that npm has removed the sabotaged versions, meaning projects that rely on them should no longer be impacted.

If your application is still affected, consider downgrading to a functional version such as Colors 1.4.0. Alternatively, you can replace the original “colors” library with a fork such as “DABH/colors.js.”

For issues with “faker”: If your application is impacted, consider downgrading to a functional version such as Faker 5.5.3.

For both packages, we recommend pinning a specific version in your package.json or your lock file by removing any prefix to the version which would otherwise indicate allowable version ranges that could make for unintended upgrades.

‘Colors’ and ‘Faker’ Sabotaged: The Big Picture

Obviously, it’s relatively uncommon that a developer behind a popular open source project intentionally sabotages their work. But regardless of whether the culprit is a disgruntled developer, malicious outsider, a poorly maintained package, or someone/something else completely, the bottom line is similar: It’s really important to know what’s in your software.

Here are a few steps you might consider taking to gain additional visibility into your programs and strengthen software supply chain security:

  • Use a software composition analysis tool that integrates smoothly with your CI/CD pipeline to enable frequent, automated code scanning. This helps quickly identify dependency issues and suggest fixes.
  • Design your build pipelines to be reproducible. Vet new versions of dependencies before using them, and prefer to pin your dependency versions and install plans. Ideally, self-host your dependencies to avoid availability issues.

For more information on FOSSA’s software composition analysis solution and how it can help your organization manage open source issues like the ones with ‘Colors’ and ‘Faker,’ please click here and fill out the form. Our team will then be in touch with you shortly.