Security issues in neb and underscore

Question

this is my first question and I hope I am not coming up with something totally stupid.

I am new to JS and Node.js. I can solve easy issues on my own, but with this pollution report I need some advice.

I received the following report:

Severity: high
Prototype Pollution - https://github.com/advisories/GHSA-339j-hqgx-qrrx
Depends on vulnerable versions of binary-search-tree
Depends on vulnerable versions of underscore
No fix available
node_modules/nedb

underscore  1.3.2 - 1.12.0
Severity: high
Arbitrary Code Execution in underscore - https://github.com/advisories/GHSA-cf4h-3jhx-xvhq
No fix available
node_modules/underscore
  binary-search-tree  *
  Depends on vulnerable versions of underscore
  node_modules/binary-search-tree```

For nedb there seems to be absolutely no solution beside not using it. For underscore there is a patched version (ver 1.12.1) available which seems to solve the problem.

However:

1. I have no clue whether nedb will still be working in I update the dependency underscore

2. I have no clue how to update the dependency underscore

So community kindly advice on using nedb in general and question 1 and 2.

Maybe important to know: the application I am making is running only locally. I am using express as server and the only way I dress the app is via localhost:

Answer 1

While you commented that you no longer needed help, there are still some parts of your question that have not been addressed. For general interest, I will answer them.

I have no clue whether nedb will still be working in I update the dependency underscore

The short answer to this is "most likely yes". All 1.x versions of Underscore should be backwards-compatible with previous 1.x versions.

The honest truth is that there have been some breaking changes in the past, most of which were temporary. Roughly speaking, there are three categories of breaking changes that occurred within the 1.x release series:

• There were some accidental breaking changes, essentially bugs, which were repaired in the next patch version in most cases. This is not unique to Underscore.
• Ironically, bugfixes tend to break stuff for people who have somehow relied on the bug. Sometimes the bug in question has been around for a long time, which can cause some people to be unpleasantly surprised by the fix. This type of break is less predictable than the previous, because it depends on when the bug is discovered, but it tends to be problematic only for a very small subset of users. This is not unique to Underscore, either.
• The 1.7 release (August 2014) contained several subtle breaking changes relative to the 1.6 release (February 2014), for reasons I will not go into now. Most of those were reverted in the 1.8 release (February 2015). While upgrades from 1.9 onwards should be fairly smooth, upgrades across the 1.6-1.8 range can be quite involved, depending on your usage.

Then, there are occasionally libraries who have pinned their Underscore dependency to a tilde range, for example ~1.9.2. In this example, the library would not upgrade its dependency to Underscore 1.10 or later, even though it would probably work just fine. You can tackle such cases by using the overrides field in the package.json.

Maybe important to know: the application I am making is running only locally. I am using express as server and the only way I dress the app is via localhost

While I cannot comment on the security issue in nedb, I am the author of the security patch in Underscore 1.12.1.

If you are only running the application on localhost and you are the only person with access to the application, then the security issue in Underscore <1.12.1 can be ignored without much risk. Although it says "arbitrary code execution", just running a compromised version of Underscore is not enough to be vulnerable. In order for the leak to be exploited, you need three more ingredients:

• Your application or one of its dependencies must call _.template, because that is the function containing the leak.
• A second dependency must "unlock" the leak in _.template with a secondary leak, for example by exposing your application to prototype pollution as well (prototype pollution is the only possible unlock I'm aware of, but I don't rule out the possibility that there are others). To my knowledge, Underscore itself has never had such a leak.
• A remote attacker must be able to send JSON data to your application and have it passed through the "secondary" leak.

Alternatively, you could have a malicious second dependency that actively exploits the leak in Underscore, but such a dependency could execute arbitrary code even without any leaks.