Next.js and React security fixes of 14 October 2026: what to update
Next.js 16.4.1 and 15.5.28 close two critical holes and a denial-of-service bug, one of them in the image library under next/image. Which versions you need, how to read them from the lockfile, and why sharp matters.
On 14 October 2026 the Next.js and React teams released fixes for three security holes, two of them rated critical. They concern apps built with Next.js, and other apps that use React Server Components. This note lists the fixed versions, shows how to check an app without opening the code, and explains why the image library needs its own look.
What was fixed?#
Image optimisation, critical (GHSA-2464-fhr4-w9xw, CVE-2026-96889). A memory bug in the image library Next.js uses for next/image can let an attacker run code on the server by sending an SVG. It affects Next.js 10.0 up to 15.5.27 and 16.0 up to 16.4.0 on glibc-based Linux, which covers most servers and most Docker images built on Debian or Ubuntu. The bug itself is in sharp and is fixed in sharp 0.35.5.
React Server Components, critical (GHSA-xqc2-xf4c-x3h3). A crafted request can lead to code execution in rare cases where a response carries several typed arrays and a value the attacker controls. In Next.js it shows up in use cache functions that return typed arrays.
Server Functions, high (GHSA-h3gv-c5rc-p453). Crafted requests to server action endpoints can exhaust memory or CPU and take the app down.
None of them needs a login. When this was written, no attacks had been reported, but advisories with a patch to compare against tend not to stay quiet for long.
Which versions have the fix?#
Next.js 16: 16.4.1 fixes all three.
Next.js 15: 15.5.28 fixes the image hole and the denial of service. The typed-array hole is in use cache, which 15 does not ship as stable.
Next.js 14 and older: no fix is planned. The image hole reaches back to 10.0, so an old app on Linux should at least get sharp 0.35.5 (below) while a real upgrade is planned.
Other frameworks with Server Components (react-server-dom-webpack, -parcel or -turbopack directly): React 19.0.9, 19.1.10, 19.2.9 or 19.3.1.
How do I check my app?#
Open the lockfile in the repository (package-lock.json, pnpm-lock.yaml, yarn.lock or bun.lock) and search for these names. The lockfile shows what is actually installed; package.json only shows what was allowed.
next: 16.4.1 or 15.5.28 and up.
sharp: 0.35.5 or newer, everywhere it appears. A lockfile can hold more than one copy.
react-server-dom-*: only relevant outside Next.js, which ships its own copy.
If someone else maintains the app, these three lines are the whole question to send them: which next is installed, which sharp, and when was it last deployed.
Why sharp needs its own look#
Next.js does not bundle sharp; the package manager installs it next to Next.js. A fresh install of the fixed Next.js pulls in a fixed sharp, but an app that pins sharp itself, or uses it directly for something else, keeps its old copy until that line in package.json is raised too. Search the lockfile for sharp, not only for next.
Apps on Alpine-based Docker images (musl rather than glibc) are outside the image hole as Next.js describes it. Update anyway: the same sharp release closes several other libvips bugs.
Updating and redeploying#
Raise next to 16.4.1 (or 15.5.28), and sharp to ^0.35.5 if package.json lists it.
Install, so the lockfile follows, and check that the lockfile has the new versions.
Build and run the tests. A patch release rarely breaks anything, but an app that has not been updated in a year will get more than this patch.
Deploy. A fix in package.json does nothing until the running app is replaced.
That last step is where hosted apps get stuck. Vercel, Netlify and the rest do not rebuild your app for you; nothing changes until someone deploys a new build. Self-hosted apps in Docker need the image rebuilt, not just restarted.
If the app was exposed#
An unpatched app on Linux that serves next/image to the internet could have been attacked without anything looking wrong. Look for restarts and memory spikes in the logs around and after 14 October, and change the secrets the server holds (database, payment and email keys) if anything looks off. The denial-of-service bug leaves nothing behind but downtime.
Sources#
React: remote code execution in React Server Components (GHSA-xqc2-xf4c-x3h3)
React: denial of service in Server Functions (GHSA-h3gv-c5rc-p453)
I will update this note if the fixed versions or the reports of attacks change.
Was this useful?
More notes
PHP2Shell: how to check your website
Two critical holes in PHP were closed on 21 October 2026. How to find out whether your website has the fix, what to ask your web host, and why updating plugins does not help.
Elementor Pro CVE-2026-32475: how to check your website
A hole in Elementor Pro forms let anyone upload a PHP file and run it on the server. It was fixed in 4.2.2 on 19 August 2026 and attacked the same day. How to see your version, which forms matter, and what to look for in the upload folder.