Two Critical Next.js RCE Advisories: Check Your Exposure

On August 25, 2026, the Next.js maintainers published two critical remote-code-execution advisories. Both affected Next.js 16 releases before 16.3.3, but their older-version ranges and attack conditions were different.

If your application was in an affected range, upgrade first and investigate exposure second. Neither advisory has a safe configuration-only workaround for every affected deployment.

What happened

The first advisory, GHSA-p293-qw3h-jr36 / CVE-2026-75604, concerns applications that use both the Pages Router and App Router without Cache Components when the server runs on a Windows filesystem. It affects Next.js versions from 13.4.0 up to, but not including, 15.5.24 and from 16.0.0 up to, but not including, 16.3.3. A remote, unauthenticated attacker could achieve code execution. The maintainer states that there is no known workaround for affected Windows-hosted applications.

The second advisory, GHSA-2xp9-vwfh-vxw4, concerns Next.js image optimization of AVIF files. It affects Next.js versions from 10.0.0 up to, but not including, 15.5.24 and from 16.0.0 up to, but not including, 16.3.3. A flaw in the underlying libheif image decoder could lead to code execution while a crafted AVIF image is optimized. Next.js disabled AVIF optimization in its immediate fix while the corrected dependency propagated.

The patched releases are:

Next.js 16.3.3 or later for the 16.x line
Next.js 15.5.24 or later for the maintained 15.x line
sharp 0.35.4 or later when using its prebuilt binaries

Who was exposed

For the Windows-filesystem issue, an application needed all of the following:

An affected Next.js version
A Windows-hosted server
Both the Pages Router and App Router without Cache Components

For the AVIF issue, an application needed an affected version and a route through which attacker-influenced AVIF content could reach the Next.js image optimizer. Apps that accept image uploads or optimize images from permitted remote hosts deserve particular attention.

Being inside an affected package range is sufficient reason to patch, but it is not proof that either exploit condition was reachable.

Was VibeScan affected?

VibeScan previously had a Next.js version inside the published affected range, so we treated both advisories as urgent dependency findings and upgraded production through security remediation PR #28.

Our exposure review found:

Production runs on Vercel's managed function platform, not a self-hosted Windows server.
The application does not import next/image, configure remote image sources, accept image uploads, or provide an application-controlled AVIF optimization path.
The patched production deployment for commit cedca25 completed successfully on Vercel.
GitHub now reports zero open Dependabot vulnerability alerts for the repository.

This was an exposure assessment, not proof that exploitation never occurred. We found no application route matching the known prerequisites, but the old dependency version still required immediate remediation.

How to check your application

Start with the exact installed versions, including transitive dependencies:

npm ls next sharp
npm audit

Then answer these questions:

For the Windows issue, was production running Next.js 13.4.0 through 15.5.23, or 16.0.0 through 16.3.2?
Did that application use both the Pages Router and App Router without Cache Components?
Did any production server use a Windows filesystem?
For the AVIF issue, was production running Next.js 10.0.0 through 15.5.23, or 16.0.0 through 16.3.2?
Does the application use the Next.js image optimizer?
Can users upload images, or can an attacker select an image URL from an allowed remote host?
Could any of those sources supply AVIF content?

Do not rely only on package.json. A lockfile, deployment manifest, or software bill of materials shows what was actually installed.

Immediate response

Upgrade Next.js 15.5 to 15.5.24 or later, or Next.js 16.3 to 16.3.3 or later. Move older, unpatched release lines to one of the maintainer's patched supported lines.
Ensure sharp resolves to 0.35.4 or later if it is present.
Rebuild from a clean lockfile and deploy the resulting artifact.
Verify the production deployment, not only a preview build.
For previously exposed Windows servers or attacker-controlled AVIF processing, review application, function, and infrastructure logs for unexpected child processes, outbound connections, file writes, or crashes during the affected period.
Rotate credentials if investigation finds evidence of code execution. Do not rotate blindly without preserving useful, non-sensitive evidence first.

What VibeScan detects today

VibeScan's lockfile and SBOM scans check exact resolved dependency versions against OSV data, so they can identify a package version associated with these advisories. A version match establishes that the advisory applies to the dependency; it does not prove that the runtime exploit conditions were reachable. VibeScan's URL-only scan cannot determine installed package versions, so use a lockfile or SBOM scan, Dependabot, npm audit, or another dependency scanner for that job.

VibeScan complements that work by checking the deployed public surface for issues such as exposed secrets, unsafe headers, overly broad CORS, and other externally observable weaknesses. Package-version findings and deployed-surface testing answer different security questions; mature release checks need both.

Primary sources

Last updated: September 13, 2026.