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: https://github.com/facebook/create-react-app/pull/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.

[gaearon]

As a first step, this might (if it works) at least reduce the confusion for newly created projects: https://github.com/facebook/create-react-app/pull/11176.

[gaearon]

I'll also be reaching out to our contacts at Node/npm to see how we can solve this at the ecosystem level.

[rhalaly]

I think you should consider putting the react-scripts in the devDependencies automatically for new projects as part of create-react-app templates (JS + TS)

[rhalaly]

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.

At least, for me, this is the reason that I'm too sensitive for vulnerabilities in react-scripts...

I understand what you mean, that Create React App is a build tool so most of the audit vulnerabilities are irrelevant since this package is used in build time only.

But there's no way that vulnerability in one of the react-scripts dependencies going to cause a vulnerability in the "produced static assets"?

For example, in the list of closed referenced issues, there are some vulnerabilities related to css-what. For people like me, which are not deeply familiar with how react-scripts works, it sounds suspicious: "react-scripts is a build tool, so it not using any CSS for itself. Is this vulnerability affects the static assets that it produces for me?"

By turning off the audit for react-scripts (devDependencies + npm audit --production) we will not receive any audit vulnerabilities related to react-scripts and any other devDependencies packages. Again, I understand your point and I think that most of the audit vulnerabilities for react-scripts are irrelevant. But, if there is some chance (even the tiniest one) that vulnerability in one of the react-scripts dependencies going to cause a vulnerability in the "produced static assets", we will miss it! Can you confirm that the chance of that is totally zero?

[gaearon]

But there's no way that vulnerability in one of the react-scripts dependencies going to cause a vulnerability in the "produced static assets"?

In theory, yes, of course. In practice, if an audit produces 99.9% false positives, I think it’s fair to say that it doesn’t do its job. When there’s a real issue it gets reported through other channels because each parent package learns about it from users who flagged it. So it would reach us anyway and then we would release a fix. As already happened the couple of times there was an actual vulnerability.

[gaearon]

Can you confirm that the chance of that is totally zero?

That is not what I’m saying. I’m not saying the risk of using software is zero. If you don’t want the risk of using third-party code, you shouldn’t use third-party code at all. You can write all the code of your application (including all tooling) yourself.

When you use code written by other people you assume some of that risk. My point isn’t that using build tools is risk-free. My point is that npm audit is an inadequate mechanism to surface these issues. If I may use an analogy, a person might have a high temperature, but you don’t want to measure it with a faulty thermometer that always reports high temperature. That’s the situation we’re in now.

[rhalaly]

But there's no way that vulnerability in one of the react-scripts dependencies going to cause a vulnerability in the "produced static assets"?

In theory, yes, of course. In practice, if an audit produces 99.9% false positives, I think it’s fair to say that it doesn’t do its job. When there’s a real issue it gets reported through other channels because each parent package learns about it from users who flagged it. So it would reach us anyway and then we would release a fix. As already happened the couple of times there was an actual vulnerability.

Thank you!

But I'm just wondering loudly, putting the react-scripts under devDependencies and use npm audit --production hides all the vulnerabilities that audit finds, which, as you said, "99.9% false positives", and I agree with that.

Again, I'm totally with you about the false positive of npm audit. npm audit just reports the packages with vulnerabilities, but it doesn't know how you use that package - if the vulnerability has even been used in your source code. For example, we are using jest for unit testing - with jest I'm totally fine to move it to devDependencies and use npm audit --production since it is 100% false positive - audit doesn't know that jest is not been used in production and the vulnerability is irrelevant...

But, react-scripts is not jest since it generates the production assets, so it has a responsibility. If you have a real vulnerability in react-scripts (directly or in any of your sub-dependencies) that affects the produced static assets for production, that, as you said, already happened in the past, we will not see it... So, it hides the 99.9% false positive, which is excellent, but it also hides the 0.01% true positive - and that's the problem I see.

I don't want to miss any real vulnerability in react-scripts, even if it just has "0.01% chance" for that. I prefer to stop my CI/CD pipelines and hold down the releases for a while, and not publish assets with vulnerabilities in production - better be safe than sorry :)

How can we react ASAP in case that react-scripts will have a real vulnerability that affects the produced assets if we totally turn the audit off for this package?

That is not what I’m saying. I’m not saying the risk of using software is zero. If you don’t want the risk of using third-party code, you shouldn’t use third-party code at all. You can write all the code of your application (including all tooling) yourself.

When you use code written by other people you assume some of that risk. My point isn’t that using build tools is risk-free. My point is that npm audit is an inadequate mechanism to surface these issues. If I may use an analogy, a person might have a high temperature, but you don’t want to measure it with a faulty thermometer that always reports high temperature. That’s the situation we’re in now.

Hmm, that is not what I meant. Your previous message was a satisfactory answer for me :)

[gaearon]

I think we're in agreement here. Of course we'd like to have a mechanism for reliable security flags. One thing we've been doing historically is to tag vulnerable releases of react-scripts with npm deprecate so people notice. But yes, I agree ideally there would be a proper solution that balances the tradeoffs well. It doesn't exist now but we'll be talking to Node and npm to see if we can work something out.

[rhalaly]

Yes, we are! I'm just raising the concern that the "0.01%" of true positive vulnerabilities will be off the radar and people should be aware of that.

When Dan Abramov posts a post like this one, people will just do it 😄. But I think it is important to also let people know and be aware that with these instructions the true positive vulnerabilities will be turned off as well.

In my system, I will try to do what you've suggested but also catch deprecation messages for react-scripts (or even use npm outdated react-scripts) as a CI/CD gate to be sure that I didn't miss a security fix (implicit assumption: your reaction is fast 😄). I think it is a good balance for the current npm limitation. Please let me know if you have an even better suggestion. Thank you!

[gaearon]

One thing we can consider is to bundle dependencies at publish time. This way, they won't show up in dep trees. Startup would be faster too. I'm seeing both Next.js and Vite doing it. This would break "customization" hacks but those were never first-class supported.

[alamenai]

I've done what you recommended :

1. Move react-scripts to `devDependencies.
2. Run npm audit --production.
3. I got found 0 vulnerabilities

Thank you @gaearon ❤️ .

[DesignByOnyx]

Are we concerned at all about people who deploy their dev code? Whether it be for a quick POC, intimidation with managing build pipelines and artifacts, or general laziness? NPM audit is more paranoid than it is flawed, and I think it's an injustice to arm inexperienced developers with the sentiment "Dan Abramov says it's useless".

It seems that the maintainers of vulnerable projects are doing their part to fix the vulnerabilities - the least we could do is keep pressure on downstream projects to do the same - not matter how benign the vulnerability. I mean, the person-hours spent complaining about this the past week could have made a substantial dent in the upgrade.

Lastly, aren't most security exploits the result of some project maintainer being like "I see no way possible to exploit my code" and some hacker being like "hold my beer". I am very wary of someone declaring "this is not a real vulnerability" if they don't have substantial street cred in the hacker community.

[compulim]

@DesignByOnyx resonate with me.

Say, a package has vulnerability and CVE published. But the dev tool isn't hitting that code path. How could we count this as false positive reliably? Should someone scope it out in CVE and say, "if you hit this code path, this CVE applies to you. Otherwise, you are safe."

Not perfect, but I would suggest that we look at individual CVEs, and list out which CVE does not apply to react-scripts. And in short future, they should be fixed eventually. Or come back and fix them in the next 6 months.

npm audit --production seems a bit too automatic and could skip severe CVE that we have before. Not to mention, in an enterprise, a corporate governance policy may be used to inject npm audit for both production and development dependencies.

[jindong-zhang-git]

Hi there, npm audit --production works well for me, but yarn audit --production still found vulnerabilities...

[jindong-zhang-git]

By the way, how to avoid Github dependabot alerts?

[lil5]

Could someone explain to me why the maintainers do not just update their dependencies?

[Den-dp]

@lil5 TLDR: sometimes "just update dependencies" is not an option because of the support policy.

If we take webpack as an example of a big package with dependencies that should be always up-to-date (your statement), webpack is restricted with introducing any breaking change into minor releases (since there is a concept of support policy and LTS), meaning the tool must not break its API in any way and must work with specified versions of node.js.

At the same time, webpack dependencies may not adhere to the concept of LTS and for example, they are free to release a newer version that may drop old node.js support. So at this point, webpack can't even consume such a package since this is a breaking change (even if API is the same).

And it can get worse when maintainers of such small packages are fixing security vulnerabilities only for the latest version of their package, which leads us to another problem of why webpack can't just update their dependencies all the time.

I believe create-react-app is in the same situation.

[cronon]

@Den-dp

And it can get worse when maintainers of such small packages are fixing security vulnerabilities only for the latest version of their package, which leads us to another problem of why webpack can't just update their dependencies all the time.

Then you can talk with author of the small package. In the worst case you fork that small package and do that fix by yourself. Either it is done by CRA or I'm forking CRA and do the same thing with CRA.

We have packages and modules and functions to abstract low-level details and therefore to alleviate the burden of micro management. That also includes low-level details about npm audit warnings.

When I use something I want to spend as little time as possible on learning how to use it. And npm warnings are very expensive to learn about. Not only I myself need to go deep into the details to find out if it is real or not. I will also have to convince all my customers that it is not real.

So at this point it is a question about what is cheaper: for me to talk to every customer, or to fork CRA and fix those warnings there or not to use CRA at all.

In the very case with CRA I can use it since my customers are fine if there are only low- and moderate-level vulnerabilities and none of the high and critical ones. I rather used it as an example on how people do their judgement.

[lil5]

Currently vite is a reasonable alternative without audit messages

[mcandre]

--production is a stopgap, it does not actually remove any vulnerabilities that may be present on the developer's machine.

[seanblonien]

@lil5

Currently vite is a reasonable alternative without audit messages

As Dan mentioned in his full article, this is only because Vite bundles their dependencies in the library itself, so as to not use any node_modules at all, largely defeating the purpose of the module system.

If all packages started doing this, we would get rid of the audit warnings, but immediately lose protections provided by npm audit on client-side code (like actual vulnerabilities), there would be no deduping, and package sizes and bundle sizes could explode. Vite can do this because they are a dev dependency, but most libraries don't have that luxury, and it's a terrible precedent to set for the npm ecosystem.

[pooyaEst]

i'm curious to know why react-scripts isn't in devDependencies by default ?

[seanblonien]

Since it doesn't affect the bundle size when building, and the difference between dependencies/devDependencies is semantics at that point, the team chose to leave it in. See Dan's reason explaining it.

[paolotormon]

I have 2519 high vulnerabilities. Is this the same issue?

[kp2017-zz]

I completely disagree with this analysis. NPM audit's purpose is to help package users identify safe packages. The issue mentioned and the justification behind it doesn't hold water. The same rational could be used to justify exposing SQL injection attacks (I want to do it, I can do it, I am doing it). This project provides not warrantee or protections for its code and therefore is up to the user to take on the blunt of the responsibility. If you use this package based on the justifications described with in this issue, you will have to convince others that your rational was sound if a security breach happens. I don't think you will be successful. I would suggest using another JS library or Web Components. Currently Vue.JS have no vulnerabilities and offers much of the same functionality as React JS.

[kp2017-zz]

Angular also has 0 vulnerabilities

[icecream17]

VueJS does have vulnerabilities: (e.g.: Webpack 4.28.4 https://github.com/vuejs/vue/blob/dev/package.json https://snyk.io/test/npm/webpack/4.28.4) but everything's bundled so npm doesn't detect any dependencies. (https://snyk.io/test/npm/vue?tab=dependencies) And same with angular: https://snyk.io/test/npm/angular?tab=dependencies

[SherylHohman]

In addition to the npm command line warnings, GitHub Dependabot is also adding to the pipeline. "Vulnerabilities" highlighted at the top of our pages as persistent warnings really grabs my attention! While this format can make it easier for us tend to actual vulnerability issues on our schedule (especially since they include links to "fix" the), it could also add stress, seeing them in the first place. Which may also increase the number of people reaching out to you.
Thank you for your attempts to address this issue which is outside your control, and the great explanation. This puts my mind at ease, and I can wasting my time quit trying find fixes for these myself, and worry that if I to update a "vulnerable" package that I haven't broken CRA itself. I'll leave everything as is! Thanks for everything you do !! :-)

[jap99]

For anyone who missed it, report your complaint here in hopes of this being fixed:

https://github.com/npm/cli/issues

I have made one here; however, and you can add on to it instead of creating a new, duplicate issue:

https://github.com/npm/cli/issues/3930

[clintandrewhall]

@gaearon Sorry to ping you directly, but assuming I haven't made a mistake somewhere, it's not just npm. Github dependabot still highlights the "vulnerabilities", even when moved to devDependencies. So I don't think this is limited to npm audit.

I just noticed this in a snack project (https://github.com/clintandrewhall/bunnyghp) and found this issue when searching for a resolution. So even the simplest of projects gives a lot of noise in even the Github GUI.

I empathize... but this is going to get noisier without a solution?

EDIT: I see @SherylHohman also called this out, above.

[alexandra-stepanova]

Thank you!!!

[hai0611]

I still can't fix the error when npx create-react-app myapp , still showing the message npm audit , I really don't know what to do can anyone guide me in detail how to create create-react-app when I get this error. Thanks so much

[Samuel-Therrien-Beslogic]

Here's the workaround I'm using: Add audit=false to your .npmrc, and add "scripts": {"postinstall": "npm audit --production --audit-level=none"} to your package.json !

[icest99]

I can't believe I got stuck in this for hours because of an npm bugs. jeez, thanks you so much.

[hai0611]

Here's the workaround I'm using: Add audit=false to your .npmrc, and add "scripts": {"postinstall": "npm audit --production"} to your package.json !

After running that error, it will stop and I did the same as you and then still don't know how to continue the installation with the command

[dyedwiper]

Thanks for the helpful explanation! Just a side note: If you deploy your react app to Heroku, you can break your deployment by moving react-scripts to devDependencies. For an explanation refer to this stackoverflow answer.

@gaearon I don't know how common Heroku is for react apps but maybe you wanna add a hint in your advice.

[Samuel-Therrien-Beslogic]

Here's the workaround I'm using: Add audit=false to your .npmrc, and add "scripts": {"postinstall": "npm audit --production"} to your package.json !

After running that error, it will stop and I did the same as you and then still don't know how to continue the installation with the command

@hai0611 @twocs @pzrq I've updated my answer, make sure to have --audit-level=none

[asitsar1]

Hi, We received a report of vulnerability in our security testing.

The normalize-url package before 4.5.1, 5.x before 5.3.1, and 6.x before 6.0.1 for Node.js has a ReDoS (regular expression denial of service) issue because it has exponential performance for data: URLs.

As we expect 4.5.1 , when the library will be available?

[benjaminpeto]

Hi,

Same issue here, as well. After CRA, uninstall react-scripts from dependencies, reinstall to devDependencies, run npm audit -production, still getting a bunch of vulnerabilities. 27 vulnerabilities (16 moderate, 9 high, 2 critical)

Coming from :

ansi-html * Severity: high

ansi-regex >2.1.1 <5.0.1 Severity: moderate

browserslist 4.0.0 - 4.16.4 Severity: moderate

glob-parent <5.1.2 Severity: high

immer <9.0.6 Severity: critical

nth-check <2.0.1 Severity: moderate

Node version: 16.13.1 Npm version: 8.1.2

I don't know how to move forward with it anymore, or should I just ignore and build the app anyway.

[twocs]

Hi,

Same issue here, as well. After CRA, uninstall react-scripts from dependencies, reinstall to devDependencies, run npm audit -production, still getting a bunch of vulnerabilities. 27 vulnerabilities (16 moderate, 9 high, 2 critical)

Coming from :

ansi-html * Severity: high

ansi-regex >2.1.1 <5.0.1 Severity: moderate

browserslist 4.0.0 - 4.16.4 Severity: moderate

glob-parent <5.1.2 Severity: high

immer <9.0.6 Severity: critical

nth-check <2.0.1 Severity: moderate

Node version: 16.13.1 Npm version: 8.1.2

I don't know how to move forward with it anymore, or should I just ignore and build the app anyway.

In my experience, react-scripts is for new developers who don't mind packages that are out of date. Webpack can do everything that react-scripts can do, it's much more configurable, and it doesn't contain a myriad of outdated dependencies (actually react-scripts uses webpack 4 but hides all the complexity). Detach, uninstall react scripts, remove the scripts section of the package.json. Just write your own webpack and babel, etc. There are a lot of recent articles that explain that we need to do this because react scripts depends on 10+ month old versions. So roll your own, or migrate from CRA to Vite, Next.js, Snowpack, Gatsby or many other projects in active development. CRA is basically the MS IE that's bundled in with your OS. You don't need to use it just because it's got preferential treatment in terms of React instructionals.

[benjaminpeto]

Thank you @twocs for the solution and the great explanation! I will check this out and do as you explained. Have a good one :)

[dowlingw]

At the risk of adding more frustration to the situation, I'd like to offer what I hope is a constructive perspective to the discussion.

In my team's case - we have multiple tools (none of which are npm audit as it happens) that report vulns in transitive dependencies from create-react-app - which we must periodically assess and exempt/risk assess. This is required of us by industry regulations (PCI-DSS to name one) and has significant penalty for us if we do not keep on top of this.

As you've rightly pointed out, these vulnerabilities are usually not relevant in the context of a build-time dependency, but this process still takes significant time - and the industry tooling for managing these processes is not great, so even with exceptions in place sees us reporting and discussing these frequently.

So whilst I share your frustration, I humbly submit that the argument that addressing these issues is a "waste of time" may, in fact be - a false economy. Surely we're not the only user of CRA that is in this position (or maybe I'm the only one doing an exceptionally poor job of it, which is also possible).

Is there a middle ground here? I note that the last release of CRA is in Feb - I wonder if there is sufficient value in providing a periodic (monthly? bi-monthly?) release schedule to address this kind of problem specifically? Is there a role the community can provide in contributing to these fixes/releases?

[Deveshb15]

Hi,

Same issue here, as well. After CRA, uninstall react-scripts from dependencies, reinstall to devDependencies, run npm audit -production, still getting a bunch of vulnerabilities. 27 vulnerabilities (16 moderate, 9 high, 2 critical)

Coming from :

ansi-html * Severity: high ansi-regex >2.1.1 <5.0.1 Severity: moderate browserslist 4.0.0 - 4.16.4 Severity: moderate glob-parent <5.1.2 Severity: high immer <9.0.6 Severity: critical nth-check <2.0.1 Severity: moderate

Node version: 16.13.1 Npm version: 8.1.2

I don't know how to move forward with it anymore, or should I just ignore and build the app anyway.

Hey @benjaminpeto have you fixed this issue, I have the exact same problem.

[kp2017-zz]

I think the fix is to not use react.js

On Fri, Dec 24, 2021, 7:25 AM Devesh RB @.***> wrote:

Hi,

Same issue here, as well. After CRA, uninstall react-scripts from dependencies, reinstall to devDependencies, run npm audit -production, still getting a bunch of vulnerabilities. 27 vulnerabilities (16 moderate, 9 high, 2 critical)

Coming from :

ansi-html * Severity: high ansi-regex >2.1.1 <5.0.1 Severity: moderate browserslist 4.0.0 - 4.16.4 Severity: moderate glob-parent <5.1.2 Severity: high immer <9.0.6 Severity: critical nth-check <2.0.1 Severity: moderate

Node version: 16.13.1 Npm version: 8.1.2

I don't know how to move forward with it anymore, or should I just ignore and build the app anyway.

Hey @benjaminpeto https://github.com/benjaminpeto have you fixed this issue, I have the exact same problem.

— Reply to this email directly, view it on GitHub https://github.com/facebook/create-react-app/issues/11174#issuecomment-1000820239, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGDHRGMUZONIJLCVGZBGF3DUSRRCBANCNFSM47XBXA4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[ViniciusTxr]

I updated to react-scripts 5.0.0 and still receive the audit fix moderate

nth-check <2.0.1 Severity: moderate Inefficient Regular Expression Complexity in nth-check - https://github.com/advisories/GHSA-rp65-9cf3-cjxr fix available via npm audit fix --force Will install [email protected], which is a breaking change node_modules/svgo/node_modules/nth-check

css-select <=3.1.0 Depends on vulnerable versions of nth-check node_modules/svgo/node_modules/css-select svgo 1.0.0 - 1.3.2 Depends on vulnerable versions of css-select node_modules/svgo @svgr/plugin-svgo <=5.5.0 Depends on vulnerable versions of svgo node_modules/@svgr/plugin-svgo @svgr/webpack 4.0.0 - 5.5.0 Depends on vulnerable versions of @svgr/plugin-svgo node_modules/@svgr/webpack react-scripts >=2.1.4 Depends on vulnerable versions of @svgr/webpack

[smparadeza]

@ViniciusTxr I was able to solve similar issue by adding "css-select": "^4.2.1" in devDependencies. I deleted package-lock.json then run npm install.

[ViniciusTxr]

@smparadeza It didn't work for me because the @svgr/plugin-svgo lib is required in react-scripts. Because of this, even if I install it directly, npm will always install the version that is in the requires react-scripts too, and it will keep giving the problem in the audit fix.

RESOLVED The only solution I found that worked for me was to update my npm to version >= 8.3.0 (changelog npm 8.3.0) to use the feature overrides (doc overrides) in my package.json.

package.json:

"dependencies": {
    "react-scripts": "^5.0.0"
},
"overrides": {
    "react-scripts": {        
        "@svgr/webpack": "^6.1.2"          
    }        
},

A note: Doing this override is very dangerous in that it changes a subdependency from a dependency. This SemVer change can lead to a breakchange and cause a side effect or some unexpected behavior in the application. Therefore it must be used very carefully and with lots of testing.

[kkaplinski]

Hi, there is new release of resolve-url-loader 5.0.0 with postcss updated to version 8. Old version of resolve-url-loader which react-scripts is using has vulnerability in postcss package: https://nvd.nist.gov/vuln/detail/CVE-2021-23382.

[RT-Tap]

I'm new to react and node/npm in general so please excuse my ignorance here but after searching around I found this thread so I figured I would ask here.

When using npx create-react-app myapp, I get what some others are reporting:

8 moderate severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

However if I run npm audit fix --force I just get :

137 vulnerabilities (124 moderate, 12 high, 1 critical)

So I figured it's better to NOT try to fix these issues using the recommended method. Using just npm audit I get the following:

nth-check  <2.0.1
Severity: moderate
Inefficient Regular Expression Complexity in nth-check - https://github.com/advisories/GHSA-rp65-9cf3-cjxr
fix available via `npm audit fix --force`
Will install [email protected], which is a breaking change
node_modules/svgo/node_modules/nth-check
  css-select  <=3.1.0
  Depends on vulnerable versions of nth-check
  node_modules/svgo/node_modules/css-select
    svgo  1.0.0 - 1.3.2
    Depends on vulnerable versions of css-select
    node_modules/svgo
      @svgr/plugin-svgo  <=5.5.0
      Depends on vulnerable versions of svgo
      node_modules/@svgr/plugin-svgo
        @svgr/webpack  4.0.0 - 5.5.0
        Depends on vulnerable versions of @svgr/plugin-svgo
        node_modules/@svgr/webpack
          react-scripts  >=2.1.4
          Depends on vulnerable versions of @svgr/webpack
          Depends on vulnerable versions of resolve-url-loader
          node_modules/react-scripts

postcss  <8.2.13
Severity: moderate
Regular Expression Denial of Service in postcss - https://github.com/advisories/GHSA-566m-qj78-rww5
fix available via `npm audit fix --force`
Will install [email protected], which is a breaking change
node_modules/resolve-url-loader/node_modules/postcss
  resolve-url-loader  0.0.1-experiment-postcss || 3.0.0-alpha.1 - 4.0.0
  Depends on vulnerable versions of postcss
  node_modules/resolve-url-loader
    react-scripts  >=2.1.4
    Depends on vulnerable versions of @svgr/webpack
    Depends on vulnerable versions of resolve-url-loader
    node_modules/react-scripts

8 moderate severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force

Are these serious issues? I read somewhere (I believe it was stack overflow) that these issues are with dependencies that are only used during development so not to worry, so is that really the case? If not, is it safe/ok to ignore them? If that's a no as well can someone lead me in the right direction in terms of fixing this? I tried to figure it out for myself but it just seems that there's conflicting information in different places/threads and even between posts within this thread. I suppose it really depends on the specific packages that are deemed vulnerable but I don't have enough knowledge to judge whether these are minor errors that can be ignored or if there is some type of fix that can be applied.

Any advice is greatly appreciate!

[kp2017-zz]

My suggestion is don't use the framework if you are concerned about security. It shouldn't be used for an enterprise application because you can't justify the knowledge of these security vulnerabilities in court. The framework really doesn't offer much anymore. It's really a cool feature for databinding, but has gotten bloated beyond recognition of benefits. You would be better off learning ES 6 and managing data binding with thoughtful design.

On Thu, Feb 10, 2022 at 4:15 PM RT-Tap @.***> wrote:

I'm new to react and node/npm in general so please excuse my ignorance here but after searching around I found this thread so I figured I would ask here.

When using npx create-react-app myapp, I get what some others are reporting:

8 moderate severity vulnerabilities

To address all issues (including breaking changes), run: npm audit fix --force

However if I run npm audit fix --force I just get :

137 vulnerabilities (124 moderate, 12 high, 1 critical)

So I figured it's better to NOT try to fix these issues using the recommended method. Using just npm audit I get the following:

nth-check <2.0.1 Severity: moderate Inefficient Regular Expression Complexity in nth-check - https://github.com/advisories/GHSA-rp65-9cf3-cjxr fix available via npm audit fix --force Will install @., which is a breaking change node_modules/svgo/node_modules/nth-check css-select <=3.1.0 Depends on vulnerable versions of nth-check node_modules/svgo/node_modules/css-select svgo 1.0.0 - 1.3.2 Depends on vulnerable versions of css-select node_modules/svgo @svgr/plugin-svgo <=5.5.0 Depends on vulnerable versions of svgo @./plugin-svgo @svgr/webpack 4.0.0 - 5.5.0 Depends on vulnerable versions of @svgr/plugin-svgo @.***/webpack react-scripts >=2.1.4 Depends on vulnerable versions of @svgr/webpack Depends on vulnerable versions of resolve-url-loader node_modules/react-scripts

postcss <8.2.13 Severity: moderate Regular Expression Denial of Service in postcss - https://github.com/advisories/GHSA-566m-qj78-rww5 fix available via npm audit fix --force Will install @.***, which is a breaking change node_modules/resolve-url-loader/node_modules/postcss resolve-url-loader 0.0.1-experiment-postcss || 3.0.0-alpha.1 - 4.0.0 Depends on vulnerable versions of postcss node_modules/resolve-url-loader react-scripts >=2.1.4 Depends on vulnerable versions of @svgr/webpack Depends on vulnerable versions of resolve-url-loader node_modules/react-scripts

8 moderate severity vulnerabilities

To address all issues (including breaking changes), run: npm audit fix --force

Are these serious issues? I read somewhere (I believe it was stack overflow) that these issues are with dependencies that are only used during development so not to worry, so is that really the case? If not, is it safe/ok to ignore them? If that's a no as well can someone lead me in the right direction in terms of fixing this? I tried to figure it out for myself but it just seems that there's conflicting information in different places/threads and even between posts within this thread. I suppose it really depends on the specific packages that are deemed vulnerable but I don't have enough knowledge to judge whether these are minor errors that can be ignored or if there is some type of fix that can be applied.

Any advice is greatly appreciate!

— Reply to this email directly, view it on GitHub https://github.com/facebook/create-react-app/issues/11174#issuecomment-1035525665, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGDHRGJDDR54NFMYEKWBKZDU2QTILANCNFSM47XBXA4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[palminha]

followed the suggestion of moving it to a devDependency in my project. But it should be still considered a workaround, since other tools (e.g.: dependabot) are still claiming the issue

[mcandre]

So developers should be open to malicious attacks like the recent IPC incursion?

On Tue, Mar 8, 2022, 10:18 AM Carlos Palminha @.***> wrote:

followed the suggestion of moving it to a devDependency in my project. But it should be still considered a workaround, since other tools (e.g.: dependabot) are still claiming the issue

— Reply to this email directly, view it on GitHub https://github.com/facebook/create-react-app/issues/11174#issuecomment-1061953633, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAABJRGINFV2KTAJAXWHJWLU654T5ANCNFSM47XBXA4Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[mdalpozzo]

@gaearon You offered a solution to this issue by placing "react-scripts" in "devDependencies", but i've read in several places that it should actually be in the "dependencies" including here #2657. You actually commented on that thread as well.

so whats the proper solution here? can we put "react-scripts" in "devDependencies" and ignore any "npm vulnerabilities"?

[gaearon]

whats the proper solution here?

The solution is to loudly complain to npm until this is fixed.

[OptimusPi]

Glad I found this thread. Thanks for the tip about npm audit --production!

[dutta-pratik]

@gaearon any plan to update @svgr/webpack package in react-scripts?

[thomazcapra]

Workound to fix it here: https://github.com/facebook/create-react-app/issues/12132#issuecomment-1130249584

[AverageHelper]

How do we fix this ?

I guess make PRs along the build chain to update the vulnerable dependencies.

Or use npm audit report --production to omit dev vulns.

[MaxterBattle]

An informative thread, thank you all. The NPM tool has bit me too often.

As I understand it, the yarn package manager doesn't lead to all these spurious false positives. It seems to me that the impact of NPM's design choice on this community could be mitigated by what amounts to a documentation change: recommend that developers use yarn with create-react-app. Is that right?

I'm not just talking about docs in the package, I'm referring to https://reactjs.org/docs/create-a-new-react-app.html#create-react-app, that's is how I ultimately arrived at this issue. It currently recommends:

npx create-react-app my-app
cd my-app
npm start

What if instead I had used:

yarn create react-app smart-app

Warnings are displayed, but nothing as threatening as NPM's security spam.

Reactions?

[tnoetzel]

If the recommended fix is to move react-scripts to devDependencies, why not just have it ship that way in the first place?

[Binaryfxv]

#2353 carharwh[Carharwhip - [ ] Blockchain ](carharwhip.com)

[vaibhavM55]

@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.

@gaearon You seem one of the few people actually concerned about the begineers or newbies and their struggle. I have wasted countless hours (coming from c++ / python background), when I first came upon these errors and since I was a newbie to the whole node / npm / js environment at that time and not that experienced in the CS field, I felt very discouraged to use something new that had 10s of vulnerabilities which were either "very high" or even "critical". I actually opted out from angular for that reason. Then somehow found out you should just ignore these and then came upon your post with great explaination which calmed me down. Anyways, I had been away from the whole scene for more than a year and as usual started again with the whole npm thing and encountered the same stuff and here I am again, just to make sure I am not ignoring something critical. And have again wasted a lot of time.

I know you can't get throught the npm people, but maybe you could put a warning at the "getting started" page after the npx create-react-app <app-name> with a link to this thread. Because there it shows that the code runs without any errors which is definitely not the case 99.99% of the times. It would save a lot of people, a lot of headache, frustration and waste of time. Including you who has to explain this stuff again and again to people who are new and even people like me coming back.

Sometimes solutions are just simple. Even though it won't solve the problem of the errors, it will solve the main issue of people wasting their time and getting frustrated and opting to not use something you have worked so hard on, just because of a cosmetic issue.

[AimanKM]

Is there a better solution than moving to devDependencies?

[AimanKM]

https://github.com/facebook/create-react-app/issues/11174#issue-935928547

Hope it helps someone if your use yarn

run yarn audit --groups dependencies

https://github.com/yarnpkg/yarn/issues/8635#issuecomment-950109006

[Binaryfxv]

Nice