If your website runs on Next.js and has not been updated since October 14, 2026, update it now. That is the day Next.js published the fix for a critical flaw in its Image Optimization feature. The fixed versions are 15.5.28 and 16.4.1, so this Next.js security update has been available for more than a week.
GitHub's global advisory database added the advisory on October 22, 2026, which is when the wider alerts went out. The advisory is GHSA-2464-fhr4-w9xw (CVE-2026-96889), rated Critical. It applies to a specific setup, not to every Next.js site.
You do not need to read code to find out where you stand. A few checks give you your version and your image path, and one short message gets the rest answered by the person who built or hosts the site.
Key Takeaways
Next.js 15.5.28 and 16.4.1 carry the fix, published October 14, 2026, and added to GitHub's global advisory database on October 22, 2026.
The advisory concerns Image Optimization processing SVG files on glibc-based Linux, in Next.js 10.0.0 up to 15.5.27 and 16.0.0 up to 16.4.0.
The deployed Next.js version, the deployed sharp version, whether the site serves Image Optimization with SVG on glibc Linux, and whether a patched build is live.
Next.js 14 and older have no patched version listed, so the route is sharp 0.35.5 or later, or image optimization turned off, then a planned upgrade.
Forcing sharp, blocking SVG or turning optimization off reduce exposure, and upgrading Next.js and redeploying is the full fix.
Move to 15.5.28 or 16.4.1 and the gap closes
Vercel published the advisory in the Next.js project on October 14, 2026, together with its security update post. The advisory itself describes a flaw in Image Optimization when SVG files are processed. Next.js says the upstream memory-related flaw can lead to remote code execution when Next.js runs on glibc-based Linux.
The flaw sits upstream, in a library called librsvg that sharp and libvips use to read SVG files. It is not a mistake in your site's own pages or business logic. The sharp maintainer's advisory lists sharp versions below 0.35.5 as affected and says 0.35.5 ships librsvg 2.63.2, and GNOME's librsvg security page lists the fixed librsvg releases. The CVE record carries the same identifier.
This table shows which line you are on and what to do about it.
| Your Next.js version | Status in the advisory | What to do |
|---|---|---|
| 16.4.1 | Fixed | Confirm it is the version actually deployed |
| 16.0.0 up to 16.4.0 | Affected | Run npm install next@16.4.1, then rebuild, test and redeploy |
| 15.5.28 | Fixed | Confirm it is the version actually deployed |
| 15.0.0 up to 15.5.27 | Affected | Run npm install next@15.5.28, then rebuild, test and redeploy |
| 14 and older, down to 10.0.0 | Affected, no patched version listed | Use the sharp 0.35.5 workaround or turn off image optimization, then plan an upgrade |
Patching only counts once the new build is live. A developer who updates the code but does not rebuild and redeploy has fixed nothing for your visitors, so ask for confirmation that the deployed site changed.
Find out whether your setup sits inside the advisory's conditions
The advisory is narrower than the headlines. It concerns Next.js Image Optimization running on glibc-based Linux and processing SVG files. Glibc is a common C library on Linux, while Alpine and other musl-based environments use a different one. The host or the developer can tell you which your server uses.
Some setups may fall outside those conditions. That is a statement about the advisory's conditions, not a promise about your site, so your developer still confirms it. The Next.js image documentation and the images configuration reference describe the settings involved.
| Setup | Inside the advisory's conditions? |
|---|---|
| Self-hosted server (next start, a Node server or Docker) on glibc Linux using the built-in image optimizer | Yes, this is the path the advisory describes |
| Static export with no image server | May fall outside, since there is no Image Optimization endpoint |
| images.unoptimized turned on | May fall outside the Image Optimization condition |
| Custom image loader | May fall outside the Image Optimization condition |
| Alpine or another musl-based environment | Outside the glibc condition, for this advisory only |
| Netlify | Netlify's setup guide says next/image uses Netlify Image CDN |
| Vercel | Ask Vercel to confirm your project's image path |
As of October 22, 2026, Netlify's Next.js setup guide says the next/image component uses Netlify Image CDN. If your site is on Vercel, ask Vercel to confirm how your specific project handles images; Vercel posts its notices in its security bulletin. Any other host should answer the same question in writing.
A site that is outside this advisory is not automatically secure, and one setting does not settle every question. Image optimization can be off in one place while another image-processing path remains, so the written answer from your developer matters more than a guess.
Run five checks to name your versions and image path
Check the deployed project, not only the public page. Page source cannot reliably tell you which version is running, and a version listed in the project's package file may be a range rather than the one installed. If you have access to the project folder, or your developer can share this, the steps take about ten minutes.
- Run npm ls next sharp: In the application folder, this prints the installed Next.js and sharp versions.
- Read the lockfile: Check package-lock.json, pnpm-lock.yaml, yarn.lock or bun.lock for the resolved versions, because the package file can hold a range.
- Open next.config: In next.config.js, next.config.mjs or next.config.ts, look for output: 'export', images.unoptimized, a custom images.loader or loaderFile.
- Watch the image requests: In the browser's network tab, look for addresses that begin with /_next/image, then ask whether the application or the host's image service answers them.
- Confirm the live build: Ask when the site was last rebuilt and redeployed, since the patched version only protects you once it is live.
A lockfile can keep an older sharp version after a Next.js update, which is why the sharp version gets its own check. When you can answer the version questions and say which service answers the image requests, you can read the table above for your own case.
Send one message and get your answers in writing
The fastest free route is a written question to the person who built the site or runs its hosting. Copy this message to your developer word for word:
> Please confirm the deployed Next.js version, sharp version, runtime operating system and libc, whether /_next/image is served by the application, and whether the site uses SVG through Image Optimization. If it applies, please patch to Next.js 15.5.28 or 16.4.1, or sharp 0.35.5 or later, then rebuild, test and redeploy.
If your site sits on managed hosting, send the host a shorter question: does your image optimization service process this site's images through the sharp and librsvg path described in GHSA-2464-fhr4-w9xw, and what mitigation or patched component applies to this project? Your web hosting provider is the one to ask about the runtime and the image path.
If you are unsure who owns which answer, choosing web hosting for a small business covers what to ask a host. A PHP flaw fixed on October 21 is a different update on the host side, and the PHP security update explains it if your site also runs PHP.
Stay covered on Next.js 14 or older while you plan the upgrade
The affected range starts at 10.0.0, so Next.js 14 and older fall inside it, and no patched version is listed for those lines. The Next.js update exists for 15.5.28 and 16.4.1 only. For an older line, the route is to force sharp to 0.35.5 or later, or to turn image optimization off, and then plan an upgrade.
A major-version upgrade can need regression testing for Node compatibility, image behavior, middleware, route handling and build output. That is the reason to plan it rather than rush it on the day an alert arrives. Ask your developer for a date and a test copy of the site, and keep the interim step in place until the upgrade is live.
Use interim steps to cut exposure, and treat them as a bridge
When Next.js cannot be upgraded today, a few steps reduce exposure. None of them is a full fix, and each one belongs on a short list your developer can work through.
- Force sharp to 0.35.5 or later: This is the advisory's stated workaround and brings in librsvg 2.63.2.
- Block SVG decoding in sharp: The sharp advisory documents sharp.block with the VipsForeignLoadSvg operation, where the application controls sharp directly.
- Turn off built-in optimization: Setting images.unoptimized removes that path from the site.
- Use a custom image loader: A loader sends image handling somewhere other than the built-in optimizer.
- Stop accepting SVG through the image path: Validation or image configuration that refuses SVG reduces exposure.
A web application firewall may block known request patterns, but it is not a complete fix, so the update stays on the list. The sharp workaround covers this image-library issue only, not other October 2026 Next.js advisories, and the install-sharp guidance is where Next.js explains how it uses the library.
All of these steps buy time. Upgrading Next.js and redeploying the rebuilt site is the fix that removes the question, and it is the one to schedule. If you think the flaw may already have been used against your site, what to do in the first 24 hours after a hack is the place to start.
Pay for help only where the free answers run out
The free route comes first. Your developer or host can answer the questions above in writing, and a patch with a rebuild and a redeploy is routine maintenance. A reply that says the site is outside the advisory's conditions, or already patched, ends the matter at no cost.
A paid audit earns its fee in three cases:
- Nobody can name the deployed version or the image path: The answer has to come from inspecting the running site.
- More than one image path exists: Optimization may be off in one place while another path remains.
- The developer is unavailable and the update needs testing: Someone has to patch, test and redeploy against a deadline.
If the runtime or the image path is the unknown, a website security audit reads the deployment and tells you which of the four answers you have. Where the answers are known and the site only needs the patch, you do not need an audit.
Check your Next.js security update knowledge
Pick an answer to begin.
1. Which Next.js versions carry the fix for GHSA-2464-fhr4-w9xw?
2. Which setup may fall outside the advisory's stated conditions?
3. Your site runs Next.js 14 and no patched version is listed. What is the route?
Frequently Asked Questions About the Next.js Security Update
Is every Next.js site affected?
No. The advisory concerns Image Optimization processing SVG files on glibc-based Linux, in Next.js 10.0.0 up to 15.5.27 and 16.0.0 up to 16.4.0. Your developer confirms whether your setup meets those conditions.
What versions are fixed?
Next.js 15.5.28 and 16.4.1. Next.js published them on October 14, 2026.
Is this a sharp vulnerability?
The vulnerable component is librsvg, which sharp and libvips use. Sharp 0.35.5 or later ships librsvg 2.63.2 and is the advisory's workaround.
Is a static export affected?
A static export with no server-side Image Optimization endpoint may fall outside the advisory's stated Image Optimization condition. That is a condition of the advisory, so have your developer confirm it for your site.
Does images.unoptimized matter?
It turns off Next.js's built-in optimization path. Your developer should still review the deployment for any other image-processing path.
What should I ask my developer?
Ask for the deployed Next.js and sharp versions, the runtime operating system and libc, whether /_next/image is served by the application, whether SVG goes through Image Optimization, and confirmation that a patched build is live.
Final Thoughts
The fix has been out since October 14, 2026, and the advisory reached the wider alert lists on October 22. Next.js 15.5.28 and 16.4.1 are the fixed versions, the condition is Image Optimization processing SVG on glibc Linux, and sharp 0.35.5 or later is the workaround. Four answers settle your case: the deployed Next.js version, the deployed sharp version, whether the site serves Image Optimization with SVG on glibc Linux, and whether a patched build is live.
Once you hold those four answers, the question stops being a worry and becomes a line in your maintenance record. A static Next.js site with image optimization turned off, the way our web design builds are set up, has no image server for this flaw to reach. That is a fact about that setup, and it is why version checks and patch dates are worth knowing for any site you own.
If nobody can give you the versions or the image path, Web Leveling can read the setup, then patch, rebuild and redeploy it through our website maintenance service. We work with small and medium businesses across the country and overseas. Send us your developer's reply or your open questions, and we will tell you which of the four answers is still missing.
Terms
Terms in this Next.js security update
Tap a term to see what it means.
Image Optimization. The Next.js feature that resizes and converts images on a server before sending them to visitors.
sharp. A Node.js image library that Next.js uses for Image Optimization.
librsvg. The upstream library that reads SVG files, used by sharp and libvips, where this flaw sits.
glibc. A common C library on Linux; Alpine and other musl-based environments use a different one.
Lockfile. A file that records the exact package versions installed, such as package-lock.json.
Static export. A Next.js build that produces plain files with no server running image optimization.
