PRNext 0.1.16: the React security update

PRNext 0.1.16-alpha requires React, React DOM and react-server-dom-webpack 19.3.1. The release is available on npm and includes the aligned React dependency floor.

The upstream advisories concern remote code execution in React Server Components and denial of service in Server Functions. An installation that updates only React can still retain an outdated decoder.

What changed in this release

The App Router dependency checks reject React 19.3.0 and mixed installations that leave the RSC decoder behind. A separate release security floor also checks the required versions independently of npm audit advisory coverage.

These checks help prevent a known outdated combination from becoming a new build. They do not replace dependency monitoring or prove the absence of unknown vulnerabilities.

These fixes concern React Server Components and Server Functions in applications that use the affected capabilities. The framework update keeps the relevant packages aligned, but it does not replace a review of application-specific dependencies. A dependency listed elsewhere in your workspace can still be separate from the code embedded in a deployed build.

Update all three React packages

Run the following command in your project, then inspect your lockfile to confirm the resolved versions.

Check the lockfile after installation and review any package-manager overrides or duplicate React copies. Keeping React DOM and react-server-dom-webpack at a different release can leave the rendering stack inconsistent. The command updates the package set; the application still needs its normal build and browser validation.

Terminal
npm install @thomas.f/prnext@0.1.16-alpha react@19.3.1 react-dom@19.3.1 react-server-dom-webpack@19.3.1

Rebuild and restart the application

Updating node_modules does not replace JavaScript already bundled in a deployed application. Rebuild the app and deploy the complete updated output, then restart it.

Keep framework and native PRNext package versions aligned. For standalone deployments, rebuild the complete output for the target operating system and architecture rather than copying only a new executable.

Updating node_modules on a development machine does not change an existing container image or standalone artifact. Produce a new build from the corrected dependency tree, then restart the service that actually serves it. Verify the deployed generation with a page request and a representative Server Action when your application uses them.

Keep Node.js current separately

The React fixes and the Node.js runtime are separate updates. Updating Node alone does not fix these React advisories; installing PRNext does not update the Node executable or a deployed container image.

After the update, test your application’s Server Actions, authentication, dynamic pages and error handling before returning to your usual deployment workflow.

Verify the Node executable used by the service, not only the version shown in an interactive terminal. A process manager or container can select another executable. Restarting with the corrected runtime and checking the service output closes that gap between the development environment and the process accepting requests.

Sources and further reading

Back to the blog