Help, npm audit says I have a vulnerability in react-scripts!

[gaearon]

npm audit is broken for front-end tooling by design

Bad news, but it's true. See here for a longer explanation.

If you think you found a real vulnerability in react-scripts

If you know that it affects CRA users because you understand what the vulnerability is, report it here as soon as possible.

If you're not sure but your CI is failing or you're worried about what npm audit tells you, keep reading.

Do not file new issues based on npm audit if you don't 100% understand the problem.
They will be closed (see why below). If you really need to discuss it, reply in this thread instead.

npm audit says there's a warning about vulnerabilities in my project

Open package.json. You will find this:

  "dependencies": {
    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "react-scripts": "4.0.3"
  }

Take react-scripts and move it to devDependencies (if you don't have it, create it):

  "dependencies": {
    "react": "^17.0.2",
    "react-dom": "^17.0.2"
  },
  "devDependencies": {
    "react-scripts": "4.0.3"
  },

Then, ensure you run npm audit --production rather than npm audit.

This will fix your warnings.

But isn't this just ignoring the problem?

No.

Create React App is a build tool. In other words, it doesn't produce a running Node application. It runs at the build time during development, and produces static assets.

However, npm audit is designed for Node apps so it flags issues that can occur when you run actual Node code in production. That is categorically not how Create React App works.

This means that the overwhelming amount of "vulnerability" reports we receive for transitive dependencies are false positives. Despite literally a hundred issues with thousands of comments about npm audit warnings in react-scripts, throughout the years not a single one of them (to the best of our knowledge) has ever been a real vulnerability for CRA users.

This is a huge waste of everyone's time. Mostly of yours, but of ours too.

But I still see these warnings when creating a new project or running npm install

Yes, unfortunately that's how npm works since v6. You can bring it up with npm. If enough people complain, maybe they'll rethink this decision. It is unfortunately actively hostile to build tooling.

Note that you can run npm install --no-audit to suppress them.

I know the transitive dependency has a fix, how can I try it?

If you already know that [email protected] has the fix that you need, but react-scripts hasn't yet updated to it, you can try your luck using that version forcefully. With Yarn, you can do it using resolutions. With npm, you might need to wait for overrides or npm audit fix overrides integration to land first (it's not implemented yet). You can also try npm-force-resolutions.

But can't a build tool have vulnerabilities, too?

Yes, in principle.

The few times there was an actual vulnerability, it was reported separately, and we released patches as soon as it was possible. You can always report real vulnerabilities here, but please do this if you understand the difference between a real vulnerability and a false positive. For example, a "Regex DDOS attack" can never be a real vulnerability for a development-time tool. If you're not sure, you're welcome to ask in this thread, but please keep it brief and to the point so that the thread doesn't become unreadable.

Really, the worst problem is that when there is a real attack poisoning the build toolchain, we won't know about it because it will be buried underneath the 99.9% of false positives.

[jacobbroughton]

Can't blame people for being concerned, big red '96 high risk vulnuerabilities' is sure to get everyone's attention. Thanks for the update though.

[gaearon]

Yeah it's pretty frustrating. And also understandable because many people don't know what things like "regex ddos" means or even how webapps work in general. So I understand that it looks scary.

[bcagarwal]

@gaearon Thanks for the update. However, if we have seen/ are seeing there are hundreds of issues with thousands of comments on those 96 vulnerabilities (as you said 'false positives'), this should have been fixed at the very first place. You must agree that people must have wasted their time as well after seeing those vulnerabilities. Also, there are no documentation to categorize those (at least I am not aware of). So, not everyone would know if they are false positives or real vulnerabilities.

Thank you again for your help. Hope this should be fixed soon so that people would not raise same issue again and again.

[gaearon]

However, if we have seen/ are seeing there are hundreds of issues with thousands of comments on those 96 vulnerabilities (as you said 'false positives'), this should have been fixed at the very first place

I'm not sure what you're suggesting. These are not issues with Create React App, but with low-level dependencies of transitive packages. Like I said, they are almost always irrelevant because they don't make sense in the context of a build tool. So there is nothing to "fix". Eventually the low-level dependencies update, and we pull in the updates in the next update. But it's a lot of churn and unnecessary release work just to work around the warnings which are not relevant.

You must agree that people must have wasted their time as well after seeing those vulnerabilities.

I am referring to people's time, not to my time. It is a waste of time for our users. This is why I made this issue for a centralized explanation. We'll also move react-scripts to devDependencies so that these warnings aren't reported by default.

It wasn't our idea to show these warnings. npm added this without considering the ecosystem impact on build tools.

Also, there are no documentation to categorize those (at least I am not aware of).

I don't know what kind of documentation we could provide here. Each CVE is annotated with an explanation of the type of the mistake (e.g. "prototype pollution" or "regex ddos"). These are generally well-described if you look for information about those. But we can't provide you some automated way to understand which ones affect a build tool. To understand this, you need to have an idea of how build tools work, and how the dependency is used. This isn't something we can teach in a day, but if you research each issue yourself for a little bit, you will be able to figure it out. If not, we can help in this thread.

Hope this should be fixed soon so that people would not raise same issue again and again.

I don't know what you want to be fixed. The way npm audit works is fundamentally at odds with the way build tools work. So we'll keep having this issue. But hopefully the move to devDependencies (as this thread suggests) will make it less prominent.

[frankthoeny]

What if the low-level dependencies of transitive packages are deprecated and there is no fix until those low-level dependencies are updated?

[gaearon]

What if the low-level dependencies of transitive packages are deprecated and there is no fix until those low-level dependencies are updated?

My question is what are you trying to fix, precisely? If the issue is real and affects CRA users, then we'll need to work with the packages up the tree to find who can solve the issue. If the issue does not affect CRA users, then it's up to you how you want to approach it. I don't think it makes sense for the CRA maintainers to solve issues that are out of scope of CRA's usage.

If all you want to fix are npm audit warnings, then the first post in this thread explains how. (Move react-scripts to devDependencies.)

[ako-v]

Hi.
I moved react-scripts to devDependencies as you said, but it does not solve the reporting problem, and I still get npm audit warnings.
thank you for your help.

[ptamarit]

Could react-scripts use caret ranges for all its dependencies, or is it too idealistic to assume that the maintainers of these dependencies respect semantic versioning?

[gaearon]

I moved react-scripts to devDependencies as you said, but it does not solve the reporting problem, and I still get npm audit warnings.

Yes, you're right. It appears that it's also necessary to use npm audit --production rather than npm audit.
I amended the original post.

Unfortunately, that probably means that even changing the default won't fix the warnings that people see creating a new project. This is something we (probably?) can't fix without npm or hijacking console output. (Edit: #11176 may help.)

Could react-scripts use caret ranges for all its dependencies, or is it too idealistic to assume that the maintainers of these dependencies respect semantic versioning?

The problem is usually with deeply transitive dependencies, so carets in the middle of the tree usually take care of this anyway. It is pretty risky to use carets at the react-scripts level because it's an integration package, and so it is much easier for something to break accidentally even if a dependency released a patch. It's also not going to help realistically in cases where the transitive dependency fix comes with a major bump, and everything in the middle has to be upgraded.

[bcagarwal]

To understand this, you need to have an idea of how build tools work, and how the dependency is used. This isn't something we can teach in a day, but if you research each issue yourself for a little bit, you will be able to figure it out. If not, we can help in this thread.

Not everyone is an expert on how the build tools work. Would definitely love to know how CRA build tool works. Appreciate any help.

[gaearon]

@bcagarwal I empathize with this but I really don't know what we should be doing here. I feel out of my depth. npm added these warnings without consulting or working with the build tool ecosystem, and now an untold number of person-years is being spent chasing this security theater. I am beyond frustrated by this, as I imagine you are, but I don't know who and how can solve this.

[fmalk]

This is my own override for a freshly minted [email protected]:

"overrides": {
    "svgo": {
      "nth-check": ">=2.0.2"
    },
    "react-scripts": {
      "postcss": ">=8.4.31"
    }
  },

found 0 vulnerabilities