Create-react-app: react-scripts package.json pulls in webpack-dev-server v3.2.1 which has a vulnerable version of jquery bundled

[mecorusfc]

Describe the bug

The package.json for react-scripts pulls in version 3.2.1 of webpack-dev-server. In the /client directory of webpack-dev-server (in the node_modules under react-scripts) there is a file called live.bundle.js that includes v3.3.1 of jquery. OWASP Dependency Checker flags this version of jquery with CVE-2019-11358 because versions before 3.4.0 of jquery have a vulnerability.

Steps to reproduce

Use create-react-app. That brings in the vulnerable dependency.

Expected behavior

Would prefer that package.json of react-scripts brings in a later version of webpack-dev-server such as 3.7.2. In that version, the live.bundle.js brings in the v3.4.1 version of jquery which is not vulnerable based on the CVE above. This should fix it for us and not give us a medium level vulnerability.

Actual behavior

See description above. Please advise on when this can be fixed. Thanks, Mike

[heyimalex]

Did you try recovering your dependencies? We depend on webpack-dev-server 3.2.1, which depends on jquery ^3.2.1, which will resolve to the latest 3.x minor. It's annoying, but there's not much we can do on our end.

[rovansteen]

Since webpack-dev-server only runs during development this is actually not a real vulnerability. But if you do really care about it you can force it to resolve a certain version by using yarn's resolutions.

[mecorusfc]

To answer heyimalex, I've tried multiple methods of doing that including deleting my node_modules and also getting rid of the global cache and letting him build that from scratch. It always insists on bringing in exactly 3.2.1 and not 3.4.1. I can cause a top level webpack-dev-server to be the version I want but the one under /node_modules/react-scripts/node_modules will always be 3.2.1. Surgical npm updates don't help.

To answer rovansteen, on that subject of only during development, I tried moving react-scripts to a dev dependency but so many things broke on the npm install that I gave up (after spending days on it). I notice all the examples and instructions point to having react-scripts as a prod dependency. Should react-scripts work as a dev dependency? If so, should I try again and report the issues I found when I try that? Alternatively, should react-scripts bring in webpack-dev-server as a dev dependency instead of prod as it is doing now?

[rovansteen]

See https://github.com/facebook/create-react-app/issues/1764 about the reason create-react-app does not use devDependencies. What I mean is that the so called vulnerability never runs in production because webpack-dev-server only runs when you are developing, so there is no reason to worry about it.

[mecorusfc]

1764 convinced me more that react-scripts should include webpack-dev-server as a dev dependency. Not sure why it mistakenly includes it as a prod dependency. Also, the explanation that a vulnerability is not a vulnerability because it doesn't get run in production doesn't work with security/compliance/risk/audit folks. If the file is deployed with the production code, it is there. With the large compliance penalties in the news, we can't really take a chance so we are forced into yarn if we want to be compliant with regulations in the US and around the world.

However, it sounds like the solution to quite a few problems with create react app is to use yarn. Is there a statement somewhere in the documentation saying you must use yarn with create react app? Should I put in an issue on the documentation for this? It would seem that if your solution for compliance is yarn, that should be specified very clearly in all documentation one could read about using create react app, quick start guides, etc... Alternatively, you could increase the version dependency in the react-scripts package.json on webpack-dev-server to point to the 3.7.2 version of webpack-dev-server instead of 3.2.1. Is there some reason why that is not an acceptable solution? Are there too many breaking changes in that higher version?

[heyimalex]

@mecorusfc webpack dev server 3.2.1 isn’t “vulnerable”, jquery 3.2.1 is. Is that version of jquery always being pulled when you re-install? When you removed node modules did you also delete yarn.lock and/or package-lock.json before reinstalling?

[rovansteen]

The problem is not about bumping _a_ dependency, the problem is that a lot of these so called vulnerabilities have been popping up lately and we are not always in a position to update all of these dependencies in a timely manner. Some of them might be tied to other dependency constraints which contain breaking changes, which needs to be tested etc.

I fail to understand the security issue here. Unless you pull in that version of jQuery in your own code it won't be in your bundle thus the code won't run anywhere. But if that somehow is still an issue you can always build your bundle on a non-production server or remove node_modules after building.

[heyimalex]

@rovansteen Eh, I’m sympathetic to people with draconian IT policies. If this was bugging a ton of people, ie npm audit warned on fresh installs, I would try and get the dependency upgraded quickly just to make beginner ux nicer. But as it stands there’s nothing we can do; we’re literally not depending on a vulnerable version of jquery.

[rovansteen]

I agree with you about the user experience, you want to be able to start or install a new create-react-app without any warnings. But I also think it is good to educate people what these vulnerability warnings actually mean.

[mecorusfc]

"But as it stands there’s nothing we can do; we’re literally not depending on a vulnerable version of jquery." I'll answer all the posts above soon but I'd like to address this one. In your package.json in /react-scripts, you specifically call out webpack-dev-server v3.2.1 (instead of a later version that is available). webpack-dev-server v3.2.1 has jquery in it's live.bundle.js. It also calls it out in its package.json. I can report that on the webpack-dev-server list but they have already fixed it in their later release and that will be their answer. More later...

[heyimalex]

@mecorusfc Ah, I see now. So you're using some full node_modules scan separate from npm audit, and that scan is picking up the bundled code included in the package. I'm... less sympathetic to this, because _on top_ of it not being an actual vulnerability, _and_ not being visible to the vast majority of our users, the bundled code literally is not used. You could rm client/live.bundle.js and nothing would break.

I think an update to webpack-dev-server is _probably_ coming soon anyway pending work in #7259. I don't think it's going to make it into 3.1, but probably the release after.

[mecorusfc]

Your opinion that it is not a vulnerability is not shared by security experts. Also, the "the code is not used" argument is not a valid argument from a security or hacking point of view.

However, thank you for providing a couple of good options. We can certainly do some post-processing on the node_modules directory even though that is not ideal and will require a bit of extra work for all the projects. But the better answer is that there is hope for a fix in the future. Note that there is already a better version of webpack-dev-server available right now! That is version 3.7.2 (available now). And if you were to fix the package.json in /react-scripts to point to that already-fixed version, it would simplify things for people who are required to be in compliance with various regulations.
In addition, I have verified that I can use yarn to force the resolution but it does cause some other warnings that I will have to investigate. More later. Thanks, Mike

[mecorusfc]

I've verified I can fix this with yarn. I added this to the package.json:
"resolutions": {
"webpack-dev-server": "^3.7.2"
},
It got warnings about peer dependencies needing to be at a higher version for webpack but doesn't appear to cause any issues. It will be a reasonable workaround until #7259 updates the dependency on webpack-dev-server.

Thanks for sticking with me and helping me to come to a solution.