Next.js 15.5.24 and 16.3.3 patch two critical RCE flaws

Two critical fixes in one release

Next.js has shipped a security release patching two vulnerabilities rated critical, according to a practical guide published on dev.to. The fixed versions are 15.5.24 on the 15.x line and 16.3.3 on the 16.x line. Both issues can end in remote code execution, and the affected ranges are broad enough that most unpatched deployments should treat the update as urgent rather than routine.

CVE-2026-75604: remote code execution on Windows hosts

The first flaw, tracked as CVE-2026-75604, affects Next.js applications hosted on machines that use a Windows filesystem. The advisory ranges cited by dev.to cover Next.js 13.4 and later below 15.5.24, plus 16.0 and later below 16.3.3. Both Pages Router and App Router applications are in scope when the server runs on Windows and Cache Components are not in use.

Two details stand out. First, the advisory lists no workaround for an affected Windows-hosted application; upgrading is the required path. Second, the condition concerns the runtime environment, not the developer laptop: a Linux production deployment is outside the Windows filesystem condition described by this CVE. That does not make an old Next.js version safe overall, because the second advisory applies regardless of platform.

GHSA-2xp9-vwfh-vxw4: AVIF image optimization RCE

The second advisory concerns AVIF processing in the Next.js Image Optimization path. The dev.to write-up attributes the problem to the underlying image-processing stack: when an attacker-controlled AVIF image is optimized, the result can be remote code execution. Affected versions are listed as 10.0.0 and later below 15.5.24, and anything below 16.3.3, a reach that goes back to the very start of the 10.x era.

The question that determines exposure is whether an untrusted party can push an AVIF image into that optimization path. The guide points at the usual suspects: user-uploaded avatars, marketplace images, CMS-controlled assets, externally supplied image URLs, remote image domains and image proxies. It also warns against turning that audit into a reason to delay: upgrade first when on an affected version, then review configuration to understand exposure and where additional controls may belong.

Verify the version that is actually running

The guide's central argument is that the first job is not reading vulnerability summaries but answering what is deployed. The version range written in package. does not tell you what sits inside the deployment artifact; the lockfile and the installed package do. Suggested checks include npm ls next, or asking Node directly with node -p "require('next/package.').version", with equivalent commands for pnpm, Yarn and Bun.

The platform check matters just as much: node -p "process.platform" returns win32, linux or darwin, and a win32 result deserves immediate attention if the application is on an affected version.

Upgrading means installing [email protected] or [email protected], confirming the resolved version, and committing the lockfile alongside the manifest, since the lockfile is what keeps CI and production on the version you reviewed.

Ship it like a normal release

A security upgrade still needs ordinary release verification. The guide recommends running the production build, the project's usual tests, typecheck and lint if it is already part of the workflow, and not padding the checklist with commands the project does not normally use. After that, smoke-test the routes most likely to reveal regressions: dynamic routes, API routes, image-heavy pages, upload flows and authenticated pages, including at least one page that exercises next/image if the application uses it.

The sequence the guide lays out is simple: patch applied, application builds, critical flows work, patched deployment reaches production. A package update sitting in a development branch has not reduced production exposure. It closes with a recommendation to add a small CI guard that stops a vulnerable Next.js version from reaching deployment again.

Why it matters

Both patched issues are critical remote code execution bugs, and one of them affects every Next.js release from 10.0.0 onward. The exposure question for the AVIF flaw is one many teams cannot quickly answer no to, because image optimization routinely handles assets that originate from user-controlled sources such as avatars, CMS content and remote URLs. The Windows flaw, meanwhile, ships with no workaround at all. The recurring operational lesson is that a patch only counts once the patched version is verified in the deployed artifact — not in the manifest, and not on a branch.