Next.js Critical Vulnerabilities in August 2026: What to Update
On August 25, 2026, the Next.js team released versions of 15.5.24 and 16.3.3that address two critical vulnerabilities in remote code execution without authentication. The release was released a day earlier than the original plan after the discovery of the second problem.
The update is especially important for self-hosted projects that use the built-in Next.js image optimization or run on a Windows server. But you need to check any production project on a vulnerable version: the conditions of the two problems are different, and the absence of Windows does not exclude the risk when processing AVIF.
Short answer: Next.js 15 needs to be updated to at least
15.5.24, Next.js 16 - minimum to16.3.3. For Next.js 14 and older branches, there is no separate corrected release in the August advisory: if the version is in the affected range, a controlled transition to the supported branch will be required. After the update, be sure to reassemble and re-deploy the app.
What happened on August 25, 2026
Initially, Next.js announced a fix for one critical vulnerability on August 26. After the discovery of an additional problem, the release was postponed to August 25 and two security advisory were published.
| Vulnerability | Risk conditions | Affected Versions | Corrected at |
|---|---|---|---|
RCE during AVIF processing, GHSA-2xp9-vwfh-vxw4 |
Next.js Image Optimization processes an attacker-controlled AVIF image | >=10.0.0 <15.5.24as well as version 16 below 16.3.3 |
15.5.24, 16.3.3 |
RCE on Windows, CVE-2026-75604 / GHSA-p293-qw3h-jr36 |
Windows file system, sharing Pages Router and App Router without Cache Components | >=13.4 <15.5.24, >=16.0 <16.3.3 |
15.5.24, 16.3.3 |
Both problems allow an attack without authorization, but the presence of a vulnerable version does not yet describe the actual exposure of a particular project. To assess the risk, you need to check the placement method, router configuration, image processing, and input data sources.
AVIF Image Optimization Vulnerability
The first problem is in the library libheifwhich it uses sharp, and Next.js applies sharp in the built-in Image Optimization API. A specially prepared AVIF file may cause the code to execute on the server during image optimization.
The advisory indicates a critical score of 9.5 on CVSS 4.0. Vulnerability is important not only for sites that explicitly publish .avif in the repository. A dangerous scenario occurs when a server-side optimizer can acquire and process an image controlled by an external user or a third-party source.
Check if:
- whether the component is used
next/imageon pages with user-generated content; - are external sources allowed through
images.remotePatternsor oldimages.domains; - whether users, providers, or integrations can change the URL of the image
- whether there is an image upload in the CMS, personal account, catalog or marketplace;
- do AVIF files pass through
/_next/imageon its own server; - whether the external URL is proxied to the optimizer via the API or a custom loader.
Fixed versions temporarily disable AVIF optimization until the upstream fix goes through the dependency chain. This can change the size and way AVIF is delivered, so after the patch, you need to check not only the security, but also the actual image upload and performance metrics.
Do not try to replace the update with only a ban on the extension .avif in the form. The MIME type, file contents, and processing path may not match the extension. The official patch remains the main way to close the issue.
RCE on Windows Servers
The second vulnerability received an identifier CVE-2026-75604It refers to applications that simultaneously use Pages Router and App Router, run without Cache Components, and are hosted on the Windows file system.
According to the official advisory, Linux and macOS are not affected by this problem. This does not make the old version of Next.js safe as a whole: the AVIF vulnerability remains separate.
Check the project according to four conditions:
- The Next.js production process is actually running on Windows, not just being built on a Windows machine.
- Directories exist in the project at the same time
pagesandappwith working routes. - This is a vulnerable version of Next.js.
- Cache Components are not enabled.
There is no known workaround for affected Windows applications. You can not consider the transfer as a reverse proxy or an additional WAF rule as a full-fledged replacement for the patch. The priority action is to update the dependency and deploy a new build.
How to quickly determine the version and risk conditions
Start with the actual version in each production repository:
npm ls nextFor pnpm and Yarn:
pnpm list next
yarn why nextYou can check the version directly from the installed package as follows:
node -p "require('next/package.json').version"Do not be limited to the range in package.json. Line like ^15.5.0 does not prove that production is already using 15.5.24. Check the lock file, the latest build artifact, and the deployment log.
Then check the project configuration and structure:
git ls-files "app/**" "pages/**" "src/app/**" "src/pages/**"rg "remotePatterns|images\.domains|image/avif|cacheComponents" next.config.* src app pagesIf rg not set, use an IDE search or your system's in-house tools. No string found image/avif does not cancel the update: the entire processing path of the input image is important.
How to update Next.js to a fixed version
Perform the update through the repository and a regular CI/CD, and not with a command on the production server.
Next.js 16
npm install next@16.3.3Next.js 15
npm install next@15.5.24Equivalent for pnpm:
pnpm add next@16.3.3And for Yarn:
yarn add next@16.3.3After installation, check diff package.json and lock file. The security patch should not be confused with a bulk update of React, Node.js and dozens of unrelated dependencies: a small and intuitive diff is easier to check and roll back.
Reproducible sequence for a project with npm:
npm ci
npm run lint
npm test
npm run buildOnly run scripts that are actually defined in the project. If there are few automatic tests, supplement them with manual validation of critical user scenarios.
What to do with Next.js 14 and earlier
The August release provides fixes for supported branches 15.5 and 16.3. At the same time, AVIF-advisory includes versions starting from Next.js 10, and Windows-advisory - starting from 13.4 if the other conditions are met.
For a legacy project, the procedure is as follows:
- Record the exact version, production OS, and image processing method.
- Map the configuration to both advisory, not just the CVE number.
- Check the official list of corrected versions: there is no separate patch for 14.x in this release.
- Prepare the transition to 15.5.24 or 16.3.3 according to the official upgrade guide.
- Perform a migration to staging and check for incompatibilities before production.
Switching from the 14th branch to the 15th or 16th is not a usual replacement for the patch version. Such a release may affect cache behavior, routing, React, and build, so a separate rollback plan is needed.
What to check after updating
Successful team next build does not mean that the site is working correctly. Conduct a smoke test in an environment as close as possible to production.
| Area | What to check |
|---|---|
| Images | local and external images, AVIF, WebP, /_next/imageerrors sharp, file sizes |
| Routing | routes from pages and app, dynamic pages, middleware, redirects |
| Business scenarios | login, forms, application, cart, order, payment, personal account |
| API | Route Handlers, Routes APIs, Server Actions, webhooks, and external integrations |
| SEO | server-rendered HTML, canonical, robots, sitemap, response codes and metadata |
| Observability | 4xx/5xx, latency, Node.js logs, optimizer errors and memory consumption |
Pay special attention to the images. Fixed versions disable AVIF optimization, so compare Core Web Vitals and the amount of files transferred before and after the release. Safety is more important than temporary image size degradation, but the performance issue needs to be seen and planned for, not detected through a drop in conversion.
After the first deployment, observe errors and key user actions. Keep the previous working artifact until the end of the control period.
Why WAF and CDN do not replace the patch
Both August issues occur inside Next.js server processing or its dependencies. External filtering can reduce the attack surface, but does not confirm the elimination of vulnerable code.
For the Windows problem, the official advisory directly states that there is no known workaround. For AVIF, the corrected versions change the behavior of the optimizer. Therefore, a secure strategy consists of a dependency update, a new build, and a production check, rather than a single rule on the perimeter.
If the project is hosted on a managed platform, check its official release-specific security notice. However, the version of Next.js in the repository and the next build should still be clear to the team.
Priority of actions for business
If a company has multiple sites and apps, first update public systems that:
- receiving user images or displaying content from an external CMS;
- work on self-hosted Next.js;
- hosted on Windows
- contain a personal account, payment, personal data or administrative interface;
- use an unsupported Next.js branch;
- have no proven rollback process.
For a one-time patch, a controlled security release is sufficient. If there is no inventory, old projects are not collected, and the dependency update regularly breaks production, the problem is already related to architecture support. In this case, it is useful audit and development of high-load backend or technical evaluation of the project on the page development in Next.js.
A practical example of the migration of an existing store can be viewed in the case study Autopilot78: Next.js, SEO and custom adminThere, the transfer of the technological platform was carried out along with the preservation of the catalog, user scenarios and the search structure.
Free SEO audit of your website
Leave a request and our specialists will find areas of search traffic growth.
FAQ
What versions of Next.js do I need to install after the August release?
For branch 15, you need a version not lower than 15.5.24, for branch 16 - not lower than 16.3.3. It is these versions that are listed as corrected in the official advisory dated August 25, 2026.
Is Next.js vulnerable on Linux?
Windows vulnerability CVE-2026-75604 does not affect Linux and macOS. But AVIF Image Optimization RCE is not limited to Windows, so the Linux project on the affected version also needs to be checked and updated.
Is the project safe if we didn't include AVIF in next.config.js?
You can't say this for one setting. Check the entire image path: next/image, external sources, custom downloads, CMS and requests to /_next/image. Regardless of the result, the official patch remains the recommended action for the vulnerable version.
Do I need to update if the site is hosted on Vercel or another platform?
First, read the official notice of your provider: the managed platform may apply additional measures. But do not transfer the output between different hosting providers and do not leave the vulnerable dependency uncontrolled. The next production build should use the corrected version.
Can I just disable Image Optimization?
This may reduce the specific attack surface, but does not replace the update or close the Windows vulnerability. For affected Windows applications, the official advisory does not offer workaround.
What if the project stays on Next.js 14?
Determine if the configuration is included in the affected scenario and prepare the migration to the supported branch. There is no separate corrected version of 14.x in the August release, and major migration should be checked for staging.
Is it enough to update package.json?
No. You need to update the lock file, reassemble the application, deploy a new artifact, and make sure that production really works on the corrected version.
