The npm react-scripts package is the build toolchain behind Create React App, and as of 2025 it sits on a foundation that the React team has officially deprecated, which makes its aging transitive dependencies the main thing you need to manage for security. If you have an existing app scaffolded with create-react-app, you are running react-scripts, and you have probably seen a wall of npm audit warnings that will not go away with a simple fix. This guide explains why, and what to do about it.
What react-scripts does
react-scripts bundles the entire build and development toolchain for a Create React App project: webpack for bundling, Babel for transpilation, ESLint for linting, Jest for tests, and a dev server. The point of the package is that you do not configure any of that yourself. Your package.json just calls into it:
{
"scripts": {
"start": "react-scripts start",
"build": "react-scripts build",
"test": "react-scripts test"
}
}
That convenience is also the security challenge. Because react-scripts owns the whole toolchain, it pins a large, deep tree of build-time dependencies, and you inherit whatever versions it chose.
The deprecation that changes the calculus
In February 2025 the React team officially sunset Create React App. The recommendation for new projects is to use a framework like Next.js or a build tool like Vite. For existing apps, CRA continues to work in maintenance mode, but the writing is on the wall.
This matters for security because a deprecated tool does not get proactive dependency updates. The last significant feature release of react-scripts landed in April 2022, and the transitive dependencies it pins have aged accordingly. That is the root cause of the audit noise so many teams see.
Understanding the audit warnings
Run npm audit on a typical CRA project and you will likely see dozens of advisories, many rated high or critical. Before you panic, understand where they come from:
npm audit --production
The --production flag is the key insight. The overwhelming majority of react-scripts advisories are in devDependencies, in build tooling like webpack loaders, PostCSS plugins, and test utilities. These run on your machine and in CI, not in the browser bundle you ship to users. A vulnerability in a build-time dependency has a very different threat model from one in code that executes in your users' browsers.
That does not make dev-time advisories harmless. A malicious or vulnerable build dependency can compromise your build machine, poison the output bundle, or exfiltrate secrets from CI. But it does mean you should triage by where the dependency actually runs before treating every finding as an emergency.
The trap to avoid is npm audit fix --force. On a CRA project that command will frequently try to install a major-version bump of react-scripts or a conflicting transitive version, and it routinely breaks the build. Resist it.
Safe ways to handle react scripts npm advisories
You have a few realistic options, roughly in order of effort.
First, triage and accept dev-only findings you cannot fix. Document that they are build-time only and move on. This is legitimate risk management, not negligence, as long as the reasoning is recorded.
Second, use overrides to force a patched transitive version without touching react-scripts itself:
{
"overrides": {
"nth-check": "^2.1.1",
"postcss": "^8.4.31"
}
}
Test the build after each override. Some overrides are safe; others break a loader that expected the old API.
Third, and most durable, migrate off CRA. Moving a react-scripts app to Vite is usually a day or two of work for a mid-size project and it eliminates the entire class of stale-toolchain advisories at once. The React team's own guidance points here, and the audit surface after migration is a fraction of what CRA carries. For teams comparing scanner results before and after a migration, our SCA product shows the transitive path that each advisory traces through.
Keeping react-scripts safe while you still run it
If migration is not on the near-term roadmap, treat the CRA app like any other dependency-heavy project. Commit your lockfile so builds are reproducible. Run npm audit in CI but gate on production dependencies rather than failing on every dev-time advisory. Keep an eye on the small number of advisories that genuinely touch runtime code, for example anything in a package that ends up in the shipped bundle, and prioritize those.
A software composition analysis pass adds context the raw npm audit output lacks: it tells you which advisories are reachable from your production bundle versus which are build-only, so you spend effort where it changes your risk. That reachability distinction is exactly what turns a scary count of 60 advisories into a short, actionable list.
FAQ
Is npm react-scripts safe to use in 2025?
It still works, but Create React App is deprecated as of February 2025 and react-scripts no longer receives proactive dependency updates. It is safe to keep running short term if you triage audit findings by where they execute and use overrides for critical transitive fixes, but migrating to Vite or Next.js is the durable answer.
Why does react-scripts have so many npm audit warnings?
Because it pins a large, aging tree of build-time dependencies and has not had a significant release since April 2022. Most of the advisories are in devDependencies used during build and test, not in the code shipped to browsers.
Should I run npm audit fix --force on a CRA project?
No. On react-scripts projects that command frequently forces incompatible version bumps and breaks the build. Prefer targeted overrides for specific transitive packages and test after each change.
What should I migrate react-scripts to?
The React team recommends a framework like Next.js, or Vite for a simpler client-side build. Migrating to Vite typically removes the entire stale-toolchain advisory class and is usually a one- to two-day effort for a mid-size app.