Auditing a Next.js App for the Latest RCE Vulnerability

The Next.js RCE patch dropped last week. Here's my step-by-step process for checking if a client's app is vulnerable.

When CVE-2026-75604 and the libheif/AVIF RCE vulnerability were disclosed on August 25th, I had three clients running Next.js in production. Rather than panic, I ran the same audit process on each one — and you can follow along on your own app. The goal is to move from "is this even relevant to me?" to "patched and verified" as quickly and methodically as possible.

Step 1: Check the Next.js version

Everything starts with knowing exactly what release you're running. Check the version your app is built against:

npx next --version

Identify which release branch the app is on and compare it against the patched releases. Next.js 15.x should be at 15.5.24 or newer; Next.js 16.x should be at 16.3.3 or newer. If the version falls below the patched release for its branch, the app is running an unpatched release and you need to plan an upgrade.

When I ran this across my three clients, one was on 15.2.1 — squarely in the affected range and self-hosting on Windows, which meant it was exposed to the path-traversal RCE. That one immediately got priority.

Step 2: Check if the Windows path-traversal RCE applies

CVE-2026-75604 is a path-traversal RCE, but it doesn't affect every deployment. It specifically affects Next.js deployments hosted on a Windows filesystem that use both the Pages Router and the App Router without Cache Components enabled. If you're on Linux or macOS, this particular CVE doesn't apply to you — but you should still confirm.

# Check the OS
uname -a  # Linux or macOS → not affected by CVE-2026-75604
# On Windows: check if you have Cache Components configured
grep -r "use cache" app/  # No results and on Windows → vulnerable

The combination matters: Windows filesystem, both routers in use, and no Cache Components. One of my clients was self-hosting on a Windows server with exactly that setup, so that engagement jumped to the front of the queue.

Step 3: Check if the AVIF vulnerability applies

The libheif RCE is narrower still. It only affects Next.js apps that have explicitly enabled image/avif in the images.formats array in next.config.js. AVIF is not the default — the default format list is ['image/webp'] — so if the app has never touched images.formats, this RCE does not apply.

# Check whether AVIF is explicitly enabled
grep -r "formats" next.config.*
# If no `image/avif` entry → not exposed to this path

This is the kind of check that saves you from unnecessary urgency. Two of my three clients hadn't enabled AVIF, which meant the libheif RCE was a non-issue for them even before upgrading. The Windows path-traversal CVE was the real driver.

Step 4: Check server logs for exploitation indicators

Before you patch, it's worth checking whether anyone has already tried to exploit the vulnerability against your app. Look for unusual requests to the /_next/image endpoint, especially if AVIF is enabled:

grep "/_next/image" access.log | grep -v "\.(png|jpg|jpeg|webp|avif|gif)$"
# Suspicious: requests to /_next/image with non-image or unexpected URLs

Also check for path-traversal patterns in your access logs, which would indicate someone probing for the Windows RCE:

grep -E "(\.\.\/|\.\.\\\\|%2e%2e)" access.log

If you find hits, that changes the urgency and the scope of your response — you're not just patching, you're investigating a potential compromise. In my case, none of the three clients saw exploitation indicators, which made the path forward straightforward: upgrade and verify.

Step 5: Upgrade

Once you've confirmed exposure, upgrade to the patched release for your branch:

# For Next.js 15.x
npm install next@15.5.24
# For Next.js 16.x
npm install next@16.3.3

There is no known workaround for the Windows RCE (CVE-2026-75604) — upgrading is the fix. If you cannot upgrade immediately and you have AVIF enabled, removing image/avif from images.formats is a temporary mitigation for the AVIF RCE while you plan the upgrade:

// In next.config.js:
images: { formats: ['image/webp'] }

Note that this mitigation only addresses the AVIF path. It does nothing for the Windows path-traversal RCE, which requires the upgrade.

Step 6: Audit dependencies for related vulnerabilities

RCE disclosures often come with related findings in the dependency tree, so don't stop at Next.js itself. Run a full audit:

npm audit

One related finding that can surface is shell-quote (CVE-2026-9277). Check whether it's present and at what version:

npm ls shell-quote
# If present at <= 1.8.3, upgrade or override to 1.8.4

Dependency audits are easy to skip when you're focused on a headline CVE, but the related advisories are often the ones that bite you later. Make it part of the same pass.

Step 7: Document and verify

After upgrading, don't just deploy and walk away. Run the full test suite, confirm that image optimization still works for whatever formats you have enabled, and verify the version the app is actually running:

npx next --version  # Should show the patched release for the app's branch

Document what you found, what you changed, and when. If a client ever asks "are we patched against the August 2026 advisories?", you should be able to answer with a record, not a guess.

I completed all three client audits within a few hours of the disclosure. Two needed immediate upgrades. The third had already pulled 16.3.3 through their dependency-update pipeline, so they were protected as soon as the release landed — which is the ideal outcome, and a good argument for automating dependency updates.

This is why I tell clients: security isn't a one-time thing. It's a continuous process of monitoring disclosures, auditing dependencies, and patching quickly. The vulnerability you don't know about is the one that gets you.

Need help with this?

Get in touch — I take on a few new clients each month.