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 some-library@x.y.z 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.

[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 react-scripts@2.1.3, 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 react-scripts@3.0.1, 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 react-scripts@3.0.1, 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?

[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

[ColmBhandal]

This seems to work:

npm audit --omit=dev

Slight modification of this comment by @AimanKM.

[Download]

Just created a new app with create-react-app but it still adds react-scripts to dependencies i.s.o. to devDependencies:

{
  "dependencies": {
    "@testing-library/jest-dom": "^5.16.5",
    "@testing-library/react": "^13.4.0",
    "@testing-library/user-event": "^13.5.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-scripts": "5.0.1",
    "web-vitals": "^2.1.4"
  }
}

Is this simply not released yet?

Also, I think it's weird that @testing-library stuff is under dependencies. I would expect that under devDependencies as well.

[andresmanikis]

Wouldn’t it be useful if CRA docs could have a section that lists the false positives? I think that most of the people using CRA just don’t have the time or knowledge to decide if a false positive is safe to ignore. What I’m trying to say is that the maintainers of CRA would probably be in a very good position to decide if a vulnerability is a false positive and therefore could add it to the docs.

For example, at the time of me writing this comment there is a vulnerability chain that ends in nth-check. If the current docs had a section that clearly said it is safe to ignore that particular report (with all the chain starting at react-scripts) then most of the people using CRA could go ahead and safely ignore it and also justify why they’re doing it without having to dive deep to decide themselves if it is safe to ignore.

Also, maybe we could get a handy message in the console after bootstrapping a new app that links to the docs about false positives.

Hope this helps!!!

[ansible-vogel]

npm audit is correctly identifying vulnerabilities in these packages; they're not false positives. It's true that many of these vulnerabilities may not apply to react-scripts specifically, but it's also true that these dependency vulnerabilities sometimes - even in the build environment - can have compromising behaviors with security implications.

The vulnerabilities being reported by Dependabot, npm audit, Snyk, etc. for react-scripts are not false positives; they're true vulnerabilities that *maybe are still safe to use in react-scripts due to its limited attack surface.

That, on top of good points in this thread about the dev hours spent tracking alerts down into react-scripts and trying to find out if each individual threat is being considered a false-positive for react-scripts, further supports the proposal that CRA maintains updates for the vulnerable sub-dependency versions.

Limiting npm audit to only review production (npm audit --production) is not a secure approach and can lead to missing true vulnerabilities in the dev environment.

[andresmanikis]

This PR seems to solve the current vulnerabilities but it's been on hold since March. Would it be possible for the codeowners to give it a look so that we can finally get rid of the vulnerability warnings? I understand that most probably they're false positives but having open vulnerabilities in this library is very inconvenient for the ones using it.

[bsaracalign]

Is there any update to this issue? I get same issue by snyk: https://security.snyk.io/vuln/SNYK-JS-NTHCHECK-1586032

Also, how is this package have not been updated for 8 months? Is it deprecated at this point? Does anyone have a process to go away from using react-scripts?

[Romack]

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 some-library@x.y.z 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.

Thanks for the workaround @gaearon . Question: if react-scripts is a dev dependency, any reason CRA should not create it that way? Seems like that and any other dev dependencies should be place in devDependencies from the get-go.

[bsaracalign]

If a package with "132,428" weekly downloads does not get a single update for nine months, that raises alarm bells. There must have been one line of code that should have been added to it. Additionally, your response to "I know the transitive dependency has a fix, how can I try it?" is "you can try your luck" to thousands of people instead of keeping an eye says it all. create-react-app is what it is; accept it as is, and don't expect too much since it's not the highest priority.

[ayushcs]

Does anyone know if I move "react-scripts" and "@testing-library/jest-dom" to "devDependencies". Will it break the application any how? is there any chance?

[jzombie]

@ayushcs Moving react-scripts to dev dependencies was a recommended solution right from the start in this thread.

And all Jest / testing stuff should be there anyway, so no, it shouldn't break anything.

[dyedwiper]

Does anyone know if I move "react-scripts" and "@testing-library/jest-dom" to "devDependencies". Will it break the application any how? is there any chance?

Moving react-scripts breaks your deployment if you deploy to Heroku. See: https://stackoverflow.com/questions/41932041/create-react-app-deployment-to-heroku-failed-with-react-scripts-not-found

[ayushcs]

@dyedwiper we are using bitbucket pipelines for CI and Argocd for CD @jzombie Thanks for the confirmation, I also thought so but just wanted to confirm it.

[marklouisALTER]

Nc its solved mine <3

[illume]

Are the admins open to new maintainers?

[dave9123]

Changing nth-check might fix it, not @svgr/webpack (have no idea why they don't update the dependencies)

[monico-moreno]

@dave9123 RE:

Having @svgr/webpack to the latest should fix it

Would you please be able to elaborate on how adding @svgr/webpack will fix this? (I mean, if it's something other than having a version of @svgr/webpack that is > v5.5.0)

Thx man!

[dave9123]

Sorry, just checked and it's an issue with nth-check

[monico-moreno]

Sorry, just checked and it's an issue with nth-check

@dave9123 Ah, yes, that's what we had found, to begin with; and we traced it back to a sub-dep by react-scripts.

Our (temp) Solution

For others that might benefit, following is our current solution/route. Given how react-scripts (& CRA) has not been updated in over a year and, apparently, is not going to be actively maintained, we opted for a temporary solution, to give us a few weeks to ultimately move away from using react-scripts (& CRA) (which has served its purpose, for us, extremely well).

(1) Pseudo Fork react-scripts

I know there's a way, in git, to fork a mono repo's package, but we just copied the package folder. Basically, I cloned CRA. Then I just copied the react-scripts folder into a new folder. macOS/Linux command to copy:

cp -R ./create-react-app/packages/react-scripts/*

(2) Update "Fork"'s Dependency of @svgr/webpack

In the new fork, we updated thepackage.json dependency of @svgr/webpack from v5.5.0 (which has the nth-check vuln at v1.x) to 8.0.1 (which has the nth-check vuln fix at v2.1.1).

It now looks like this in the "fork's" package.json:

"@svgr/webpack": "^8.0.1",

(3) Reference New "Fork" from our internal React App

Within our internal, React app, we changed the package.json dependency reference for "react-scripts". We changed it from having the version at ^5.0.1 to referencing our new "fork" of react-scripts, like this:

(package.json) ... "react-scripts": "git+" ...

At this point, you can rebuild internal React App, and ...

(4) ✅ nth-check Vulnerability Is Now Gone

Now when we run our vulnerability checks, the nth-check vulnerability is gone

Hopefully this helps others.

[dave9123]

Thanks, but if it's ok with you, please make a PR at @svgr/webpack's

---

From: Monico Moreno @.> Sent: Saturday, July 8, 2023 11:48:06 PM To: facebook/create-react-app @.> Cc: Dave @.>; Mention @.> Subject: Re: [facebook/create-react-app] Help, npm audit says I have a vulnerability in react-scripts! (#11174)

Sorry, just checked and it's an issue with nth-check

@dave9123https://github.com/dave9123 Ah, yes, that's what had found to begin with traced it back to a sub-dep by react-scripts.

Our (temp) Solution

For others that might benefit, following is our current solution/route. Given how react-scripts (& CRA) has not been updated in over a year and, apparently, is not going to be actively maintained, we opted for a temporary solution, to give us a few weeks to ultimately move away from using react-scripts (& CRA) (which has served its purpose, for us, extremely well).

(1) Pseudo Fork react-scripts

I know there's a way, in git, to fork a mono repo's package, but we just copied the package folder. Basically, I cloned CRAhttps://github.com/facebook/create-react-app. Then I just copied the react-scripts folder into a new folder. macOS/Linux command to copy:

cp -R ./create-react-app/packages/react-scripts/*

(2) Update "Fork"'s Dependency of @svgr/webpack

In the new fork, we updated thepackage.json dependency of @@.***/webpack> from v5.5.0 (which has the nth-checkhttps://www.npmjs.com/package/nth-check vuln at v1.x) to 8.0.1 (which has the nth-check vuln fix at v2.1.1).

It now looks like this in the "fork's" package.json:

@.***/webpack": "^8.0.1",

(3) Reference New "Fork" from our internal React App

Within our internal, React app, we changed the package.json dependency reference for "react-scripts". We changed it from having the version at ^5.0.1 to referencing our new "fork" of react-scripts, like this:

(package.json) ... "react-scripts": "git+" ...

At this point, you can rebuild internal React App, and ...

(4) ✅ nth-check Vulnerability Is Now Gone

Now when we run our vulnerability checks, the nth-check vulnerability is gone

Hopefully this helps others.

— Reply to this email directly, view it on GitHubhttps://github.com/facebook/create-react-app/issues/11174#issuecomment-1627398438, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVWWU4EGEDDITVKQDQ275ELXPGFMJANCNFSM47XBXA4Q. You are receiving this because you were mentioned.Message ID: @.***>

[AlonNavon]

Hey @Den-dp,

We're part of a startup called Seal Security that mitigates software vulnerabilities in older open source versions by backporting/creating standalone security patches - enabling more straightforward remediation in cases like this. We created an nth-check 1.02-sp1 that's vulnerability-free. As with all of our patches, it's open-source and available for free.

If relevant, check out our GitHub repo if you wish to learn more, or start using our app.

Please feel free to reach us at info@seal.security if you have any requests/questions.

[dave9123]

Hey there, is it possible to override nth-check to the modified one?

---

From: AlonNavon @.> Sent: Tuesday, August 1, 2023 6:53:46 PM To: facebook/create-react-app @.> Cc: Dave @.>; Mention @.> Subject: Re: [facebook/create-react-app] Help, npm audit says I have a vulnerability in react-scripts! (#11174)

Hey @Den-dphttps://github.com/Den-dp,

We're part of a startup called Seal Security that mitigates software vulnerabilities in older open source versions by backporting/creating standalone security patches - enabling more straightforward remediation in cases like this. We created an nth-check 1.02-sp1 that's vulnerability-free. As with all of our patches, it's open-source and available for free.

If relevant, check out our GitHub repohttps://github.com/seal-community/patches/tree/main/npm/nth-check/1.0.2/sp1 if you wish to learn more, or start using our apphttps://app.sealsecurity.io.

Please feel free to reach us at @.**@.> if you have any requests/questions.

— Reply to this email directly, view it on GitHubhttps://github.com/facebook/create-react-app/issues/11174#issuecomment-1660159135, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVWWU4FHML3ZTBXJD4REEJ3XTDU4VANCNFSM47XBXA4Q. You are receiving this because you were mentioned.Message ID: @.***>

[AlonNavon]

Hey @dave9123,

The modified version of nth-check (and other vulnerable packages) is freely available from our artifact server. You can register to use it for free, and it's a few commands to configure. After you have access to the server, you can just use the npm overrides feature like you would for any other package:

{
  "overrides": {
    "nth-check@1.0.2": "1.0.2-sp1"
  }
}

Alternatively you can download the patch file from here, apply it on the existing tag, and build it yourself.

[dave9123]

The sign-up page looks weird

---

From: AlonNavon @.> Sent: Wednesday, August 2, 2023 6:48:31 PM To: facebook/create-react-app @.> Cc: Dave @.>; Mention @.> Subject: Re: [facebook/create-react-app] Help, npm audit says I have a vulnerability in react-scripts! (#11174)

Hey @dave9123https://github.com/dave9123,

The modified version of nth-check (and other vulnerable packages) is freely available from our artifact serverhttps://app.sealsecurity.io/. You can register to use it for free, and it's a few commands to configure. After you have access to the server, you can just use the npm overrides feature like you would for any other package:

{ "overrides": { @.***": "1.0.2-sp1" } }

Alternatively you can download the patch file from herehttps://github.com/seal-community/patches/tree/main/npm/nth-check/1.0.2/sp1, apply it on the existing taghttps://github.com/fb55/nth-check/tree/v1.0.2, and build it yourself.

— Reply to this email directly, view it on GitHubhttps://github.com/facebook/create-react-app/issues/11174#issuecomment-1662064461, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVWWU4CB6M6HB72ITDKUYLLXTI5A7ANCNFSM47XBXA4Q. You are receiving this because you were mentioned.Message ID: @.***>

[AlonNavon]

How so? We use Frontegg as our authentication provider.

[dave9123]

[AlonNavon]

Hey @dave9123 , I understand now. Sorry, as the onboarding flow contains instructions to configure a development environment, it was designed to work from a laptop, not a mobile device. Definitely something we will fix in the near future, thanks for pointing this out.