DEV Community

Cover image for Next.js 16.3.3 / 15.5.24 Security Patch: CVE-2026-75604 and AVIF RCE Checks
Ascent Innovate Software profile image Shruti Saraswat
Shruti Saraswat for Ascent Innovate Software

Posted on

Next.js 16.3.3 / 15.5.24 Security Patch: CVE-2026-75604 and AVIF RCE Checks

#nextjs #security #softwaredevelopment #devops

Two Critical Next.js security issues were patched this week.

If you maintain a Next.js application, the first job is not to read ten summaries of the vulnerabilities.

It is to answer four practical questions:

  1. Which Next.js version is actually deployed?
  2. Does the Windows-hosted RCE apply to this deployment?
  3. Can this application optimize attacker-controlled AVIF images?
  4. Has the patched version reached production, not just package.json?

This guide walks through those checks and finishes with a small CI guard that can stop a vulnerable Next.js version from reaching deployment again.

The patched versions

The August 2026 Next.js security release provides these patched releases:

Next.js 15.x → 15.5.24
Next.js 16.x → 16.3.3
Enter fullscreen mode Exit fullscreen mode

The release addresses two Critical issues.

Windows-hosted remote code execution

CVE-2026-75604 affects vulnerable Next.js applications hosted on machines using a Windows filesystem.

The advisory covers:

Next.js >= 13.4 and < 15.5.24

Next.js >= 16.0 and < 16.3.3
Enter fullscreen mode Exit fullscreen mode

The affected setup includes Pages Router and App Router applications without Cache Components when the server runs on Windows.

The advisory lists no workaround for an affected Windows-hosted application.

Upgrade is the required path.

AVIF Image Optimization remote code execution

A second advisory, GHSA-2xp9-vwfh-vxw4, concerns AVIF processing in the Next.js Image Optimization path.

The issue comes from the underlying image-processing stack and can lead to remote code execution when an attacker-controlled AVIF image is optimized.

The affected Next.js ranges listed by the advisory include:

>= 10.0.0 and < 15.5.24

< 16.3.3
Enter fullscreen mode Exit fullscreen mode

Again, the patched versions are:

15.5.24
16.3.3
Enter fullscreen mode Exit fullscreen mode

So let us check the application rather than guessing from memory.

1. Check the installed Next.js version

Inside the project, run:

npm ls next
Enter fullscreen mode Exit fullscreen mode

Or ask Node directly:

node -p "require('next/package.json').version"
Enter fullscreen mode Exit fullscreen mode

You might see:

15.5.23
Enter fullscreen mode Exit fullscreen mode

or:

16.3.2
Enter fullscreen mode Exit fullscreen mode

Both are below the new patched versions.

If you use pnpm:

pnpm list next
Enter fullscreen mode Exit fullscreen mode

For Yarn:

yarn why next
Enter fullscreen mode Exit fullscreen mode

For Bun:

bun pm ls | grep next
Enter fullscreen mode Exit fullscreen mode

Do not check only the version range written in package.json.

For example:

{
  "dependencies": {
    "next": "^15.5.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

does not tell you which version is currently installed in the deployment artifact.

Check the lockfile and installed package too.

2. Upgrade the supported release line

For a Next.js 15.5 application:

npm install next@15.5.24
Enter fullscreen mode Exit fullscreen mode

For a Next.js 16 application:

npm install next@16.3.3
Enter fullscreen mode Exit fullscreen mode

Then confirm:

node -p "require('next/package.json').version"
Enter fullscreen mode Exit fullscreen mode

Expected:

15.5.24
Enter fullscreen mode Exit fullscreen mode

or:

16.3.3
Enter fullscreen mode Exit fullscreen mode

Commit the lockfile along with the package change.

For npm:

git add package.json package-lock.json
Enter fullscreen mode Exit fullscreen mode

For pnpm:

git add package.json pnpm-lock.yaml
Enter fullscreen mode Exit fullscreen mode

For Yarn:

git add package.json yarn.lock
Enter fullscreen mode Exit fullscreen mode

The lockfile matters because that is what keeps CI and production on the version you reviewed.

3. Check whether the Windows-specific advisory reaches your deployment

CVE-2026-75604 has a deployment condition that matters: the affected server runs on a Windows filesystem.

Check the runtime environment rather than assuming from the laptop used for development.

In Node:

console.log(process.platform);
Enter fullscreen mode Exit fullscreen mode

Possible values include:

win32
linux
darwin
Enter fullscreen mode Exit fullscreen mode

You can also run:

node -p "process.platform"
Enter fullscreen mode Exit fullscreen mode

A result of:

win32
Enter fullscreen mode Exit fullscreen mode

deserves immediate attention if the application is on an affected Next.js version.

A Linux production deployment is not the Windows filesystem condition described by CVE-2026-75604.

That does not make an old Next.js version safe overall.

The AVIF advisory is separate.

4. Check the Image Optimization path

Now inspect how the application handles images.

Search the Next.js configuration:

grep -R "image/avif" \
  next.config.* \
  2>/dev/null
Enter fullscreen mode Exit fullscreen mode

You can also search the project for image configuration:

grep -R "images:" \
  next.config.* \
  2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Then ask a more useful question:

Can an untrusted user cause an AVIF image to reach the Next.js Image Optimization path?

Look at areas such as:

  • user-uploaded avatars
  • marketplace images
  • CMS-controlled images
  • externally supplied image URLs
  • customer-generated content
  • image proxies
  • remote image domains

The security advisory is specifically concerned with AVIF images being optimized.

Do not turn this into a reason to delay the patch while investigating every image path.

Upgrade first when you are on an affected version.

The configuration review helps you understand exposure and where additional controls may belong.

5. Build the application after upgrading

A security upgrade still needs normal release verification.

Run the production build:

npm run build
Enter fullscreen mode Exit fullscreen mode

Then run the project's normal checks:

npm test
npm run typecheck
Enter fullscreen mode Exit fullscreen mode

If linting is part of the project:

npm run lint
Enter fullscreen mode Exit fullscreen mode

Do not add commands your project does not normally use just to make the checklist longer.

Use the release checks that actually protect the application.

6. Smoke-test the routes that matter

After upgrading, test the paths most likely to reveal a regression.

For example:

/
login
dashboard
dynamic routes
API routes
image-heavy pages
upload flows
authenticated pages
Enter fullscreen mode Exit fullscreen mode

If the application uses next/image, include a page that exercises image optimization.

If users upload images, test that flow too.

The purpose is simple:

security patch
      ↓
application still builds
      ↓
critical flows still work
      ↓
patched deployment reaches production
Enter fullscreen mode Exit fullscreen mode

A package update sitting in a development branch has not reduced production exposure yet.

7. Verify the deployed version

This is easy to miss.

The repository may show:

next@16.3.3
Enter fullscreen mode Exit fullscreen mode

while an old container, server, or deployment is still serving traffic.

Capture the version during the build.

For example:

NEXT_VERSION=$(node -p "require('next/package.json').version")

echo "Building with Next.js ${NEXT_VERSION}"
Enter fullscreen mode Exit fullscreen mode

In GitHub Actions:

- name: Show Next.js version
  run: node -p "require('next/package.json').version"
Enter fullscreen mode Exit fullscreen mode

A deployment log that records the framework version gives you something concrete to verify later.

8. Add a CI guard

If this application is likely to live for a while, do not rely on somebody remembering the advisory six months from now.

Install semver as a development dependency:

npm install --save-dev semver
Enter fullscreen mode Exit fullscreen mode

Create:

scripts/check-next-security.mjs
Enter fullscreen mode Exit fullscreen mode

Add:

import nextPackage from "next/package.json" with {
  type: "json",
};

import semver from "semver";

const version = nextPackage.version;

function fail(message) {
  console.error(`Security check failed: ${message}`);
  process.exit(1);
}

if (semver.lt(version, "15.0.0")) {
  fail(
    `Next.js ${version} is on an older unsupported major. ` +
      "Review the current Next.js support policy and security release."
  );
}

if (
  semver.gte(version, "15.0.0") &&
  semver.lt(version, "15.5.24")
) {
  fail(
    `Next.js ${version} is below the August 2026 patched 15.x release 15.5.24.`
  );
}

if (
  semver.gte(version, "16.0.0") &&
  semver.lt(version, "16.3.3")
) {
  fail(
    `Next.js ${version} is below the August 2026 patched 16.x release 16.3.3.`
  );
}

console.log(
  `Next.js security version check passed: ${version}`
);
Enter fullscreen mode Exit fullscreen mode

Add it to package.json:

{
  "scripts": {
    "security:next-version": "node scripts/check-next-security.mjs"
  }
}
Enter fullscreen mode Exit fullscreen mode

Run:

npm run security:next-version
Enter fullscreen mode Exit fullscreen mode

And add it to CI:

- name: Check Next.js security version
  run: npm run security:next-version
Enter fullscreen mode Exit fullscreen mode

Now an older version fails loudly.

9. Do not treat a WAF rule as the completed fix

Cloudflare published an emergency WAF release on August 26 covering these Next.js issues.

Its managed rules include detection for CVE-2026-75604 and a new rule for the Image Optimizer AVIF RCE path.

That can provide another protection layer for applications behind the relevant Cloudflare WAF configuration.

It should not change the package-upgrade task.

The vulnerable application code still exists until the patched Next.js version is deployed.

Think of the layers separately:

WAF
↓
can reduce exposure to known request patterns

PATCH
↓
removes the vulnerable framework version from the application
Enter fullscreen mode Exit fullscreen mode

Both can be useful.

They do different jobs.

10. Check the support line too

Next.js currently lists:

16.x
Active LTS

15.x
Maintenance LTS
Enter fullscreen mode Exit fullscreen mode

Older majors are outside the current supported-version list.

If an application is still on an older major, this security release is a good trigger to look at the upgrade path rather than treating an unsupported line as a permanent home.

That migration may need more testing than a patch release.

Plan it accordingly.

A compact response plan

When a framework security release like this lands, I use a sequence like this:

Identify 

Which version is actually deployed?
Enter fullscreen mode Exit fullscreen mode

Match conditions 

Does the advisory apply to this hosting or feature path?
Enter fullscreen mode Exit fullscreen mode

Patch 

Move onto the fixed release.
Enter fullscreen mode Exit fullscreen mode

Verify 

Build, test, and smoke-test the application.
Enter fullscreen mode Exit fullscreen mode

Deploy 

Make sure the patched artifact is serving traffic.
Enter fullscreen mode Exit fullscreen mode

Record 

Keep the framework version visible in CI or deployment logs.
Enter fullscreen mode Exit fullscreen mode

Guard 

Prevent the vulnerable version from quietly returning.
Enter fullscreen mode Exit fullscreen mode

That gives a security advisory a clear path from announcement to production.

Sources

Editorial note

The affected versions, patched versions, deployment conditions, advisory details, commands, and final article were checked against the current Next.js, GitHub Security Advisory, and Cloudflare documentation before publication.

Top comments (0)