node-ip Maintainer Restores GitHub Repo After Archiving Due to Overblown CVE Rating

node-ip maintainer Fedor Indutny, software engineer at Signal and former Node.js TSC member, temporarily made the 'node-ip' library read-only on GitHub in response to a disputed CVE rating at the end of June. The library was restored a week later after GitHub lowered the severity of the advisory, highlighting the issue of exaggerated vulnerability ratings and the toll it takes on open source maintainers.

The node-ip package on npm is a widely used utility for working with IP addresses in Node.js applications. It provides functionalities such as retrieving your IP address, comparing IP addresses, validating them, and more. This package is popular, receiving over 16 million weekly downloads, and is used by more than 3,500 dependent projects.

GitHub Revises CVE Severity to Low#

Indutny posted on Mastodon, linking to the GitHub advisory in dispute.

“There is something that have been bothering me for past few months, and resulted in me archiving node-ip repo on GitHub,” he said.

“Someone filed a dubious CVE about my npm package, and then I started getting messages from all people getting warnings from npm audit.”

Indutny commented on the advisory issue, asking GitHub to remove it, but also noticed a pattern in other SNYK-submitted advisories on open source projects.

“I'd also comment that it is strange that I wasn't involved in any step of this process from its beginning, but yet the package users and myself had to experience its effects,” he said.

The original report was filed as a 9.8 or "critical” CVE, but after reviewing GitHub decided to keep the advisory but revise it down to a low security impact.

“GitHub got back to me and decided to lower the vulnerability rating in response to my feedback,” Indutny said. “Furthermore, they advised me to enable Private Vulnerability Reporting feature so that I could get a chance at tackling the reports before they hit all package users next time. Great response!

“SNYK still didn't get back to me, though, and I have no idea if another feedback channel exists.”

Bogus CVEs Plague Open Source Maintainers with Disruptive Downstream Effects#

Indutny, who is known for his significant contributions to the Node.js community, commented on the burden these types of overblown CVE reports place on maintainers.

“It looks like there are entities that in theory should fill the void in OSS community and provide resources for managing security reports for overloaded maintainers. (I'm looking at you SNYK)

"However, the verification process of vulnerability reports doesn't involve maintainer at all, and it sounds like the commercial interest of advisory repositories is aligned with creating more vulnerabilities and proving themselves ‘useful’ to companies that utilize them.”

“The CVE in question was marginal (it involved passing a user-controlled IP address string in a security decision context), but the tooling for flagging CVEs in npm dependencies caused a huge amount of noise and chaos for the project for minimal security benefit,” Evan Anderson, Software Engineer at Stacklok, wrote in his Software Supply Chain Security Weekly newsletter. “Clout-chasing in the vulnerability research world has real consequences for maintainers.”

Bleeping Computer’s article on this situation explored a previous incident in 2023, where a 9.8 curl CVE was revised down to 3.3 after it was disputed and further investigated.

“I am not a fan of philosophical thought exercises around vulnerabilities,” curl maintainer Daniel Stenberg said at the time. “They are distractions from the real matters and I find them rather pointless. It is easy to test how this flaw plays out on numerous platforms using numerous compilers. It’s not a security problem on any of them.”

The PostgreSQL Security Team also received a bogus CVE last year, claiming that it was possible to create a denial-of-service in a PostgreSQL 12.2 by sending repeated SIGHUP (or reload) signals to the primary PostgreSQL process. Their request, which should be common courtesy for any open source security team, was that anyone with a vulnerability report it first to the PostgreSQL Security Team for evaluation.

The PostgreSQL Security Team has been maintaining its list of known vulnerabilities for nearly 20 years. The team works with all reporters to determine what is a valid vulnerability and to provide transparency to our users around security issues.

Another set of bogus CVEs were filed earlier this year in the micromatch project, which gets 64 million weekly downloads. Researchers reported high-severity ReDoS (Regular Expression Denial of Service) vulnerabilities but were not able to provide concrete examples of how they could be exploited in real-world scenarios. Maintainer Jon Schlinkert commented on the theoretical nature of the report, saying he “get[s] these issues all the time for things that can't even be a vulnerability unless you do it to yourself.”

Others commented that these types of reports degrade the quality of CVEs overall, likening them to a “Boy Who Cried Wolf” scenario.

”I just commented on this issue because I was frustrated at something being elevated to a ‘security’ issue when it seems more like non-optimal code,” Matt Passell commented. “It might seem like a small thing, but it puts a significant burden on the project maintainers and it means that those of us who are downstream of the project have to keep filing paperwork explaining why this really isn't a significant risk.”

Engaging in intellectual exercises at the expense of open source maintainers is counterproductive and detrimental to the community. These types of incidents highlight the limitations of traditional CVE scanners, which rely heavily on CVE data to deliver value. Moreover, when CVEs are treated as the primary measure of a security tool's effectiveness, the severity ratings can become exaggerated to justify the cost of the tool and elevate the status of the researchers.

Bogus CVEs not only burden maintainers with unnecessary work but also disrupt downstream projects, ultimately harming the open source ecosystem as a whole. We need a better way for maintainers to dispute dubious reports to ensure that security efforts are focused on genuine threats.