Technology & security · · 8 min read
Two critical Next.js vulnerabilities: What do you need to do now?
Two critical security vulnerabilities have been confirmed in Next.js. Whether your company website, shop or customer portal is affected depends on the features and versions in use. Have your production deployment checked: the version of your application that is actually deployed. The research for this article is current as of 22 October 2026.
What has happened with Next.js?
Next.js is software for web applications that also run on a server. The vendor published two security advisories on 14 October 2026. Both describe possible remote code execution, or RCE: under certain conditions, attackers could execute their own code on the server.
The image vulnerability is identified as GHSA-2464-fhr4-w9xw / CVE-2026-96889. It affects Image Optimization, the server-side optimisation of images. SVG image content controlled by an attacker must reach the vulnerable processing through an accepted image source. This route is described on Linux with the glibc system library.
For the image vulnerability, the vendor lists Next.js 10.0.0 up to and including 15.5.27, as well as versions greater than 16.0.0 up to and including 16.4.0. The status of exactly 16.0.0 remains unresolved: NHS England also lists this version as affected; the research contains no clarification from the vendor. This does not give 16.0.0 the all-clear. The research specifies no explicit boundaries for pre-release versions.
The cache vulnerability GHSA-673q-mjm6-r5xr affects 16.0.0 up to and including 16.4.0. The vendor’s advisory lists no known CVE identifier. The required combination is App Router for managing pages, Cache Components for caching, and a function marked with “use cache” that returns multiple Typed Arrays – arrays with a defined data type. Image optimisation and sharp are not listed as prerequisites for this vulnerability; the advisory states no restriction to glibc or self-operated servers.
How dangerous are these two vulnerabilities in practice?
Both receive a score of 9,5 under CVSS 4.0, a system for rating the technical severity of vulnerabilities. According to the assessment, network attacks are possible without prior privileges or user interaction. The technical prerequisites must still be met.
The research documents public demonstration code, a Proof of Concept or PoC, only for the image vulnerability. An author describes code execution through image optimisation; its effectiveness has not been independently confirmed. No substantiated public attack code was found for the cache vulnerability.
The reviewed sources do not document active exploitation or successful compromises through the routes examined. The CISA-KEV catalogue of known exploited vulnerabilities, with data current as of 21 October 2026, contained neither the image CVE nor a match for the cache identifier. Neither a PoC nor an attempted attack proves a successful compromise. The absence of a KEV entry does not guarantee freedom from attacks.
Which versions fix these two vulnerabilities?
The following minimum versions relate exclusively to these vulnerabilities. The research lists no separate corrected releases for older Next.js branches. Ask for any necessary version migration to be scheduled.
With Next.js 15.5.28, the version number alone is not enough: its package description, the manifest, allows sharp as an optional dependency with ^0.34.3 || ^0.35.5. The older branch therefore remains permitted. A lockfile records the specific package versions selected and may still contain an old sharp version. What matters is the version actually used by Next.js. 16.4.1 and 16.4.2 already declare ^0.35.5.
- Next.js 15: 15.5.28 is the first official fix for the image vulnerability. The sharp image library actually in use must also be at least 0.35.5.
- Next.js 16: 16.4.1 is the first fix for both vulnerabilities. 16.4.2 is the verified successor that retains the fixes, not a newly declared minimum version.
- sharp: at least 0.35.5. The corrected prebuilt packages contain librsvg 2.63.2 for SVG processing. If librsvg is linked separately from the system, the maintainer requires it to be updated to 2.63.2.
How do I check whether my website is affected?
The check requires access to the project or the hosting management interface, not root privileges, meaning full administrative access to the server. If you do not have this access, your operator carries out the check.
Source code, lockfile, installation and production deployment must be distinguished: the source code describes functions, while the lockfile records selected dependencies. A local installation and an updated project do not yet prove that the running service has been updated.
- Clarify responsibilities: Ask separately for your website, shop and customer portal whether Next.js is involved and who operates the application.
- Check package files: Look for next and sharp in package.json. This file may contain version ranges; package-lock.json, pnpm-lock.yaml or yarn.lock record specific versions.
- Inspect the installation: If an npm-compatible installation is available, run npm ls next sharp --all in the project directory. npm is a package manager. Take account of all copies of sharp, particularly the one used by Next.js. If packages are missing, request the resolved dependency tree from your agency.
- Have the prerequisites checked: Check image sources, SVG processing and glibc-Linux separately from App Router, Cache Components and “use cache” return values. Finding no match in your own code is not enough to give the all-clear.
- Obtain evidence of the production state: Select the active deployment in the hosting management interface. Cross-check the corresponding source code and lockfile revisions against the build log, the record of how the application was built. Have the versions actually deployed confirmed.
What should I write to my agency or hosting provider?
Copy this request and add your domain:
“Hello, please check our website at [Domain] for GHSA-2464-fhr4-w9xw / CVE-2026-96889 and GHSA-673q-mjm6-r5xr. Please specify the production versions of Next.js and sharp, including any multiple sharp instances and the instance used by Next.js. Provide evidence from the corresponding lockfile revision and the active deployment with its build log. Check Image Optimization, accepted image sources, SVG processing, the image-processing service and glibc-Linux separately from App Router, Cache Components and use cache returning multiple Typed Arrays. If an update is needed, please subsequently confirm the production versions and the date, time, time zone and identifier of the corrected deployment. If the website is not affected, please provide the specific technical reason. Thank you.”
What should you do if an immediate update is not possible?
According to the vendor, there is no known workaround for the cache vulnerability, meaning no known alternative measure. The vendor recommends an immediate update even if you are not aware of a matching function in your project.
For the image route, the sharp maintainer documents blocking SVG processing with sharp.block({ operation: ["VipsForeignLoadSvg"] }). Developers must ensure that this takes effect in the process actually in use. This does not help against the cache vulnerability. SVG detection alone and dangerouslyAllowSVG: false do not provide proven protection.
The research does not document a specific protective rule from Cloudflare or a WAF, a filter for web requests. General protection features do not replace evidence that a patch has been applied.
Have the packages and lockfile updated, the application rebuilt and the corrected deployment released. npm ci uses the existing lockfile without changing it. A restart without updated packages does not close the vulnerability.
Frequently asked questions about the Next.js security vulnerabilities
WordPress and plugins are up to date – is that enough?
A website using only PHP/WordPress is not affected solely because of these Next.js advisories. Any additional Next.js frontend must be checked separately. WordPress, PHP and browser versions do not establish its update status.
Does Cloudflare provide protection?
A specific protective rule for these identifiers is not documented in the reviewed information. General protection features do not confirm coverage. Request evidence of the corrected production versions.
I have a static website – am I affected?
Without the server-side functions described, the prerequisites for these attack routes are absent. Ask for confirmation of whether only ready-made files are served or whether a Next.js application or image processing also runs.
Next.js 15.5.28 – am I safe?
The manifest still permits the older sharp branch ^0.34.3. Have the lockfile and production deployment checked to confirm that Next.js actually uses sharp 0.35.5 or later. This statement applies only to the image vulnerability examined.
Vercel/Managed Hosting – do I need to do anything?
Have the exact state of your deployment confirmed. The research does not document automatic, complete protection for all Vercel deployments. With Managed Hosting, where the hosting is managed for you, responsibilities and protective measures depend on the provider and the service used.
How can I recognise an attack?
A blocked web request does not prove a successful compromise. Ask the operator to investigate any specific suspicion. The reviewed information does not document confirmed compromises through these routes.