Two Next.js Flaws Expose Self-Hosted Servers to Remote Code Execution

Next.js moved its August security release forward after finding a second critical flaw, then shipped two fixes for unauthenticated remote code execution. One path begins when the framework optimizes an attacker-controlled AVIF image. The other affects certain applications running on a Windows filesystem.

The fixes are Next.js 15.5.24 and 16.3.3. Self-hosted operators must upgrade and redeploy. Neither the release nor the two repository advisories reports exploitation in the wild, names victims, or quantifies exposed deployments.

AVIF processing reaches native code

Next.js uses the sharp image-processing library for its Image Optimization API. sharp, in turn, uses libheif to decode AVIF images. The Next.js advisory says a flaw in that underlying library can reach remote code execution when Next.js optimizes attacker-controlled AVIF content.

The decoder is the critical boundary.

The path is network-reachable and requires no prior account. It does require the application to pass an attacker-controlled AVIF image into the affected optimizer. A deployment that never enables AVIF optimization or never lets an untrusted party choose the optimized input is outside that specific path.

The patched Next.js releases disable AVIF optimization until the upstream libheif correction reaches the framework’s dependency chain. AVIF files are therefore served without that optimization rather than sent through the vulnerable decoder. This is a deliberate security change that can alter image size and delivery behavior after the update.

Windows routing exposes another path

The second issue, CVE-2026-75604, affects applications that use both the Pages Router and App Router without Cache Components while the Next.js server runs on a Windows filesystem. The advisory identifies path traversal as the underlying weakness and rates the outcome as critical remote code execution.

Linux and macOS servers are not affected by this Windows-specific flaw. Windows alone is also insufficient: the application must use the stated combination of routing systems without Cache Components. The vendor says there is no workaround for an affected Windows-hosted application.

Comparison of the AVIF optimization and Windows routing paths, including their prerequisites, affected releases, and fixed versions.

Figure details

The left column shows an unauthenticated request supplying an attacker-controlled AVIF image to the Next.js Image Optimization API, which reaches sharp and the vulnerable libheif decoder before remote code execution. The right column shows an unauthenticated request reaching a Windows-hosted Next.js application that uses both the Pages Router and App Router without Cache Components, where path traversal can lead to remote code execution. Both columns converge on the fixed releases: Next.js 15.5.24 and 16.3.3. The AVIF fix disables AVIF optimization until the upstream library fix arrives. Linux and macOS are outside the Windows-specific path.

Fixed releases change behavior

For the AVIF issue, affected versions are Next.js 10.0.0 through releases before 15.5.24, plus 16.0.0 through releases before 16.3.3. The Windows issue affects Next.js 13.4 through releases before 15.5.24, plus 16.0.0 through releases before 16.3.3. Next.js 15.5.24 and 16.3.3 supersede the affected releases on their supported lines.

The Next.js team tells operators, “Please patch your Next.js dependencies to maintain the security of your applications.” Changing package.json or a lockfile is only the expected state. Production remains exposed until the rebuilt application is deployed and every old server instance is gone.

Start by recording the version and platform in each running deployment:

node -p "require('next/package.json').version"
node -p "process.platform"
npm ls next sharp

Then inspect next.config.js, next.config.mjs, or next.config.ts for images.formats, image/avif, remotePatterns, and the older domains setting. Inventory applications that contain both pages/ and app/ trees, and confirm whether Cache Components are enabled. Build manifests and source declarations are claims; process-level output from the deployed instance is the artifact to measure.

Inventory runtime evidence after deployment

Treat the two pre-patch paths as separate hunts. For the image path, review requests to /_next/image for AVIF inputs, attacker-selected remote URLs, unusual bursts of optimizer errors, worker exits, or restarts. A fetched or staged AVIF establishes exposure to processing. It does not establish that native code executed.

On Windows, correlate pre-patch requests with application errors, unexpected files written under the service account, and child processes launched by node.exe. Those runtime effects carry more weight than a request alone. Preserve Windows event logs, endpoint telemetry, reverse-proxy records, application logs, and deployment records for the vulnerable interval before rotating or rebuilding the host.

Verify every running instance

Every running instance needs the fix.

Deploy Next.js 15.5.24 or 16.3.3 across every self-hosted web process, worker, container, and Windows service. Remove superseded instances from load balancers and verify the running process reports the fixed version. Confirm AVIF requests no longer enter the old optimization path, and confirm affected Windows applications were rebuilt and restarted rather than merely changing their lockfiles.

Run the version and platform commands against each production instance, then send a controlled AVIF request through the application’s normal image route. The expected result is a fixed Next.js version on every instance, no AVIF decode through the vulnerable optimizer behavior, no old Windows process serving traffic, and no unexpected child process or filesystem change. Any gap in pre-patch request, process, or endpoint telemetry remains documented uncertainty about earlier execution.

1-minute read

Next.js released 15.5.24 and 16.3.3 to fix two critical unauthenticated remote-code-execution paths. One reaches the libheif decoder when the Image Optimization API handles an attacker-controlled AVIF image. The other affects Windows-hosted applications that use both the Pages Router and App Router without Cache Components.

Linux and macOS are outside the Windows-specific flaw. The vendor does not report exploitation, victims, or the number of exposed deployments. Self-hosted operators remain responsible for upgrading and redeploying every instance.

Run node -p "require('next/package.json').version" and node -p "process.platform" inside each production instance across production. Inventory AVIF optimization, attacker-controlled image sources, applications with both routing systems, and Windows servers without Cache Components. Review /_next/image requests, optimizer failures, restarts, unexpected files, and child processes launched by node.exe during the vulnerable interval.

The verification target is Next.js 15.5.24 or 16.3.3 on every running process, no superseded instance serving traffic, no AVIF input entering the old optimization behavior, and no unexplained child process or filesystem change. A staged AVIF request establishes exposure to processing; it does not establish code execution.