The popular open source project, ‘ip’ recently had its GitHub repository archived, or made “read-only” by its developer.

Fedor Indutny, due to a CVE report filed against his project, started getting hounded by people on the internet bringing the vulnerability to his attention.

Unfortunately, Indutny’s case isn’t isolated. In recent times, open-source developers have been met with an uptick in receiving dubious or, in some cases, outright bogus CVE reports filed against their projects without confirmation.

This can lead to unwarranted panic among the users of these projects and alerts being generated by security scanners, all of which turn into a source of headache for developers.

‘node-ip’ GitHub repository archived

Earlier this month, Fedor Indutny who is the author of the ‘node-ip‘ project archived the project’s GitHub repository effectively making it read-only, and limiting the ability of people to open new issues (discussions), pull requests, or submit comments to the project.

The ‘node-ip’ project exists on the npmjs.com registry as the ‘ip’ package which scores 17 million downloads weekly, making it one of the most popular IP address parsing utilities in use by JavaScript developers.

On Tuesday, June 25th, Indutny took to social media to voice his reasoning behind archiving ‘node-ip’:

“There is something that have [sic] been bothering me for past few months, and resulted in me archiving node-ip repo on GitHub,” posted the developer via his Mastodon account.

It has to do with CVE-2023-42282, a vulnerability disclosed in the project earlier this year.

“Someone filed a dubious CVE about my npm package, and then I started getting messages from all people getting warnings from ‘npm audit’,” states the developer in the same post.

Node.js developers using other open projects, such as npm packages and dependencies in their application can run the “npm audit” command to check if any of these projects used by their application have had vulnerabilities reported against them.

The CVE has to do with the utility not correctly identifying private IP addresses supplied to it in a non-standard format, such as hexadecimal. This would cause the ‘node-ip’ utility to treat a private IP address (in hex format) such as ” 0x7F.1…” (which represents 127.1…) as public.

Should an application rely solely on node-ip to check if a provided IP address is public, non-standard inputs can cause inconsistent results to be returned by the affected versions of the utility.

‘Dubious’ security impact

Public sources suggest that CVE-2023-42282 had originally been scored as a 9.8 or “critical.”

Although Indutny had already fixed the issue in later versions of his project, he disputed that the bug constituted an actual vulnerability and that too of an elevated severity.

“I believe that the security impact of the bug is rather dubious,” the developer earlier wrote, requesting GitHub to revoke the CVE.

“While I didn’t really intend the module to be used for any security related checks, I’m very curious how an untrusted input could end up being passed into ip.isPrivate or ip.isPublic [functions] and then used for verifying where the network connection came from.”

Disputing a CVE is no straightforward task either, as a GitHub security team member explained. It requires a project maintainer to chase the CVE Numbering Authorities (CNA) that had originally issued the CVE.

CNAs have conventionally comprised NIST’s NVD and MITRE. Over the past few years, technology companies and security vendors joined the list and are also able to issue CVEs at will.

These CVEs, along with the vulnerability description and the reported severity rating, are then syndicated and republished by other security databases, such as GitHub advisories.

Following Indutny’s post on social media, GitHub lowered the severity of the CVE in their database and suggested the developer turn on private vulnerability reporting to better manage incoming reports and cut noise.

At the time of writing, the vulnerability’s severity on NVD remains “critical.”

A growing nuisance

The CVE system, originally designed to help security researchers ethically report vulnerabilities in a project and catalog these after responsible disclosure, has lately attracted a segment of community members filing unverified reports.

While many of the CVEs are filed in good faith by responsible researchers and represent credible security vulnerabilities, a recently growing pattern involves newbie security enthusiasts and bug bounty hunters ostensibly “collecting” CVEs to enrich their resume rather than reporting security bugs that constitute real-world, practical impact from exploitation.

Consequently, developers and project maintainers have pushed back.

In September 2023, Daniel Stenberg, creator of the well-known software project ‘curl’ rebuked the “bogus curl issue CVE-2020-19909,” a Denial of Service bug reported against the project.

Originally scored as a 9.8 or critical in severity per NVD’s history, the now-disputed CVE has had its rating dropped to a “low” 3.3 after discussions ensued questioning the tangible security impact of the flaw.

“This was not a unique instance and it was not the first time it happened. This has been going on for years,” Stenberg wrote criticizing the CVE entry.

“I am not a fan of philosophical thought exercises around vulnerabilities.” 

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

According to Stenberg, given the technical details of the “silly bug,” while it could result in unexpected behavior, it was not a security flaw that could be abused.

Yet another npm project, micromatch which gets 64 million weekly downloads has had ‘high’ severity ReDoS vulnerabilities reported against it with its creators being chased by community members inquiring about the issues.

“Can you point out at least one library that implements micromatch or braces that is susceptible to the vulnerability so we can see how it’s actually a vulnerability in the real world, and not just theoretical?” asked Jon Schlinkert, reacting to CVE-2024-4067 filed for his project, micromatch.

In the same thread, the developer, apparently after failing to receive a satisfactory proof of concept exploit from the vulnerability reporter responded with:

“I get these issues all the time for things that can’t even be a vulnerability unless you do it to yourself. Like regex in low level libraries that will never be accessible to a browser, unless you’re letting users submit regular expressions in a web form that are just used by your application.”

“I asked for examples of how a real-world library would encounter these ‘vulnerabilities’ and you never responding with an example.”

I too, recently messaged micromatch developers after a third party informed us of a potential “risk” posed by the project, as it seemed like the responsible thing to do at the time.

Unfortunately, as opposed to representing an exploitable vulnerability, it ended up being a nuisance report (much like CVE-2024-4067) that developers had already been chased about.

Other than just being an annoyance for project maintainers, the act of getting CVEs issued for unverified vulnerability reports is akin to stirring up a Denial of Service (DoS) against a project, its creators, and its wider consumer base, and for good reasons.

Developer security solutions (such as npm audit) which are designed to prevent vulnerable components from reaching your applications may trigger alerts if any known vulnerabilities are detected and depending on your settings, break your builds.

“Jackson had this problem a few months back, where someone reported a critical CVE against the project and broke builds all around the planet,” a commentator had written in 2023, reacting to the bogus curl CVE.

Rather than being a security problem with the project, as other developers stated, the issue represented the inherent nature of recursive Java data structures.

Where is the balance?

Recurring incidents like these raise the question, how does one strike a balance?

Relentlessly reporting theoretical vulnerabilities can leave open-source developers, many of who are volunteers, exhausted from triaging noise.

On the flip side, would it be ethical if security practitioners, including novices, sat on what they thought was a security flaw—so as not to inconvenience the project maintainers? 

A third problem arises for projects without an active maintainer. For example, abandoned software projects that have not been touched in years contain vulnerabilities that, even when disclosed, will never be fixed and there exists no means to contact their original maintainer.

In cases like these, intermediaries including CNAs and bug bounty platforms are left in limbo.

On receiving a vulnerability report from a researcher, these organizations may not always be able to sufficiently vet every such report independently. Without hearing from the (now absent) project maintainers, they may be compelled to assign and publish CVEs after the “responsible disclosure” window has elapsed.

No simple answer exists to these problems just yet.

Until the security research, developer, and vendor community comes together to identify an effective solution, developers are bound to get frustrated with bogus reports burning them out, and the CVE system becoming flooded with exaggerated “vulnerabilities” that may look credible on paper but are effectively moot.