@vitejs/plugin-react is the official Vite plugin that adds React Fast Refresh and JSX transformation to your build, and as of this writing the package itself carries no known published vulnerabilities on its latest 6.x release. That makes it low-risk in the sense that matters most, but "no CVE today" is not the same as "ignore it forever." As a build-time dependency it sits in a sensitive spot: it runs on your developer machines and in CI with full filesystem access.
If you have ever run npm create vite@latest and picked React, you got vitejs/plugin-react whether you noticed or not. Here's how I think about it from a security angle.
What the plugin actually does
The vitejs plugin react package wires React into Vite's dev server and build pipeline. Concretely it:
- Enables React Fast Refresh (hot state-preserving reloads) in development.
- Configures the JSX transform via Babel or, in newer setups, esbuild/SWC-adjacent tooling.
- Injects the automatic JSX runtime so you don't have to
import Reactin every file.
It is a devDependency. It does not ship code to your users' browsers directly — the output it produces does, but the plugin binary itself is a build-time actor. That distinction shapes the entire threat model.
The real threat model: supply chain, not runtime
Because the plugin executes during build with your credentials and network access, the dangerous scenario is not "an attacker sends a crafted request to the plugin in production." There is no plugin in production. The dangerous scenario is a compromised or malicious version of the package (or one of its transitive dependencies) landing in your node_modules and running arbitrary code during npm install or vite build.
This is the same class of risk behind every npm supply chain incident: a maintainer account gets phished, a typosquat gets installed, or a postinstall script exfiltrates environment variables. The mitigations are the boring, effective ones:
- Pin versions and commit a lockfile (
package-lock.jsonorpnpm-lock.yaml). - Use
npm ciin CI so installs are reproducible from the lockfile. - Turn on
npm auditand a proper SCA scan in your pipeline. - Consider
--ignore-scriptsfor CI installs where lifecycle scripts aren't needed.
The React Server Components advisory, in context
In December 2025 the React team disclosed a critical vulnerability affecting React Server Components — specifically an unauthenticated remote code execution issue in react-server-dom-webpack through deserialization of untrusted data, fixed in the 19.0.1, 19.1.2, and 19.2.1 patch lines. It's worth being precise about scope: that advisory centered on RSC bundler integrations and the separate @vitejs/plugin-rsc package that vendors the affected runtime, not the standard @vitejs/plugin-react used for client-side React apps.
If you build a conventional single-page React app with vitejs/plugin-react, that RSC advisory did not apply to you. If you were experimenting with React Server Components through the RSC plugin, you needed to update to the patched React versions. The lesson is to read advisories carefully and map them to the exact package and feature you use rather than reacting to a scary headline.
Keeping your version current
The cheapest security control here is staying reasonably up to date. Check what you have:
npm ls @vitejs/plugin-react
Update to the latest:
npm install -D @vitejs/plugin-react@latest
A minimal vite.config.js looks like:
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
export default defineConfig({
plugins: [react()],
})
When you bump the plugin, also check its peer relationship with your Vite major version — a mismatch usually shows up as a resolution warning, and running an outdated pair is where subtle build issues creep in.
Auditing the dependency footprint
The plugin pulls in Babel-related packages and Vite peers. To see the full tree:
npm ls --all @vitejs/plugin-react
npm audit --production=false
Transitive dependencies are where most real risk hides — you trust the plugin's maintainers, but do you trust every package they depend on, and every package those depend on? This is exactly the transitive blind spot that an SCA tool such as Safeguard is built to flag, mapping a known CVE in a deep dependency back to the top-level package you installed. For a broader look at choosing scanners, see our code vulnerability scanning tools guide.
Practical hardening checklist
- Commit and honor a lockfile; install with
npm ciin CI. - Run SCA on the full dev dependency tree, not just production deps.
- Subscribe to GitHub security advisories for the
vitejsorg. - Update the plugin and Vite together, and read release notes.
- Scope CI tokens so a compromised build step can't reach production secrets.
None of this is exotic. @vitejs/plugin-react is a well-maintained, widely used package, and treating it with normal supply chain hygiene is enough to keep it in the low-risk column.
FAQ
Does @vitejs/plugin-react have any known vulnerabilities?
As of this writing, the current major release of @vitejs/plugin-react has no known published vulnerabilities. That can change, so run SCA and watch the vitejs GitHub advisories rather than assuming it stays clean forever.
Is @vitejs/plugin-react a runtime or build-time dependency?
It's a build-time devDependency. It runs during vite dev and vite build and does not ship to the browser directly, so its main risk is supply chain compromise during install or build, not runtime exploitation.
Was @vitejs/plugin-react affected by the React Server Components RCE?
No. The December 2025 RSC advisory affected react-server-dom-webpack and RSC-specific integrations like @vitejs/plugin-rsc, not the standard @vitejs/plugin-react used for client-side apps. Standard React SPAs built with the plugin were not in scope.
How do I update @vitejs/plugin-react safely?
Run npm install -D @vitejs/plugin-react@latest, check compatibility with your Vite major version, read the release notes, and re-run your test build. Doing this from CI against a committed lockfile keeps the update reproducible.