Vulnerability in enzyme > cheerio > css-select > nth-check

[alexarsh]

Current behavior

There is the following dependencies tree:

├─┬ enzyme@3.11.0 │ └─┬ cheerio@1.0.0-rc.3 │ └─┬ css-select@1.2.0 │ └── nth-check@1.0.2

When nth-check@1.0.2 have the following vulnerability issues: https://snyk.io/vuln/npm:nth-check@1.0.2

Expected behavior

nth-check >= 2.0.1

Your environment

NPM version (npm -v): 6.14.15
Node version (node -v): v14.18.0
Node Process (node -p process.versions):

{ node: '14.18.0', v8: '8.4.371.23-node.84', uv: '1.42.0', zlib: '1.2.11', brotli: '1.0.9', ares: '1.17.2', modules: '83', nghttp2: '1.42.0', napi: '8', llhttp: '2.1.3', openssl: '1.1.1l', cldr: '39.0', icu: '69.1', tz: '2021a', unicode: '13.0' }

Node Platform (node -p process.platform): darwin
Node architecture (node -p process.arch): x64

Version

library	version
enzyme	3.11.0
react	17.0.2
react-dom	17.0.2

[ljharb]

This "vulnerability" is not actually one, like most ReDOS CVEs. That you can cause your own tests to hang if you intentionally craft a malicious regex and type them into your tests is not a realistic scenario, and is identical to you adding while (true) {} to your tests.

As such, like with most CVEs, you should be ignoring this one.

I'd love to upgrade to a later version of cheerio once https://github.com/cheeriojs/cheerio/issues/1585 is fixed, and presumably that'd bring in later versions of these dependencies.

[alexarsh]

@ljharb The problem is that in big companies (like the one I'm working for), vulnerability is vulnerability and it does matter for the "score". So I do need a way to upgrade nth-check

[ljharb]

I understand that such naive policies can cause problems, but the solution isn't to pretend all of these vulnerabilities are valid - it's to have a security team that can properly evaluate them.

At the moment, there is no way to use enzyme and also use a non-vulnerable nth-check, so I'm not sure what to tell you.

[ekilah]

@ljharb is there a future where Node v4 support would/could be dropped from enzyme? How would you go about deciding that? Enzyme itself hasn't been updated in quite some time, and Node v4 is over 4 years old (last release in 2018).

Though I agree the vulnerability report is ignorable, I got here trying to resolve it anyway, and I'm just curious what enzyme's take is on something like that. It seems like https://github.com/cheeriojs/cheerio/issues/1585 is not going to be resolved.

[ljharb]

@ekilah i'm sure at some point there is such a future. I maintain over 350 packages and most support node 0.4 - the age of a platform is irrelevant; everything that can be supported should be.