Next.js 16.3.8 and 15.5.27: Which of the Six CVEs Reach Your App?

On 30 September 2026 Vercel released Next.js 16.3.8 and 15.5.27 with fixes for a batch of security advisories published the same day. Six have CVE IDs, ranging from a High rated server-side request forgery in Image Optimization to a Low rated leak in the development server. The GitHub Advisory Database added the reviewed records on 7 October, which is when most dependency scanners started flagging them.

Every one of these bugs depends on a feature or configuration being in use. That makes this release a useful exercise: you can work out in a few minutes which of the six actually apply to your app.

What's affected

What each one does, in the advisories' terms:

• Image Optimization SSRF (CVE-2026-94483). "An attacker-controlled, allow-listed remote URL can lead to server-side request forgery (e.g. to private IPs)." If no images.remotePatterns are configured, the advisory says the app is not affected.
• SSG/ISR cache poisoning, self-hosted (CVE-2026-94543). A page's cache entry can be replaced with content from a different route, so every visitor gets the wrong page until revalidation. Vercel deployments are not affected.
• Catch-all cache poisoning (CVE-2026-94484). With a root-level catch-all page and SSG or ISR routes, "a single unauthenticated crafted request" can poison the shared response cache, causing cross-user content substitution and a persistent denial of service.
• Draft Mode leak (CVE-2026-94544). Pending use cache fills were shared between Draft Mode and regular requests. A regular visitor overlapping an editor's preview can receive unpublished content, and that content can be persisted into a prerendered page.
• Metadata image routes (CVE-2026-94485). opengraph-image and twitter-image routes ignored the dynamicParams option, so an attacker could request images for dynamic segments you deliberately left out of generateStaticParams().
• Dev server MCP endpoint (CVE-2026-94486). The Model Context Protocol endpoint in next dev did not check request origin, so a malicious website open in the developer's browser could read the project path, source snippets from error reports, the route list and dev logs. Production is not affected.

The 16.3.8 release notes also list a seventh fix, "Cache leak across root param values in nested 'use cache' functions", which did not have a public CVE in the GitHub Advisory Database when we checked.

How to check if you're exposed

Get the version first:

npm ls next

Then walk the table from the top.

SSRF. Open next.config.js or next.config.ts and look at the images block:

grep -n -A12 "remotePatterns" next.config.*

For every hostname pattern, ask whether you control its DNS. Your own CDN domain is fine. A wildcard over a shared hosting suffix, or a customer-supplied domain, is the kind of entry the advisory warns about.

Cache poisoning. Look for statically generated or ISR pages and for a root-level catch-all:

grep -rln "getStaticProps\|revalidate" pages app 2>/dev/null | head
ls pages/\[\[...* pages/\[...* app/\[\[...* app/\[...* 2>/dev/null

If you self-host with the Pages Router and use SSG or ISR, CVE-2026-94543 applies. If you also have a root catch-all, CVE-2026-94484 applies too.

Draft Mode. Check whether Cache Components or useCache is enabled and whether you call draftMode():

grep -n "cacheComponents\|useCache" next.config.*
grep -rln "draftMode" app src 2>/dev/null

Metadata images. Find metadata image files under dynamic segments, then check whether those segments set dynamicParams = false and whether your production build uses webpack. On Next.js 16, look for --webpack in your build script.

Dev server. Anyone running next dev on 16.x before 16.3.8 is exposed while browsing other sites.

What to do now

1. Upgrade. Move 16.x apps to 16.3.8 or later and 15.x apps to 15.5.27 or later. Rebuild and redeploy.
2. Tighten images.remotePatterns regardless. Remove wildcards you don't need, pin protocol, hostname and pathname, and drop hosts whose DNS you can't vouch for.
3. Purge caches after upgrading if you self-host SSG or ISR pages. A cache entry poisoned before the upgrade can keep serving until it is revalidated. Trigger revalidation of affected paths or clear the cache store.
4. Check your editorial flow. If editors use Draft Mode with Cache Components, review recent prerendered pages for unpublished content.
5. Update developer machines. The dev server fix only lands when developers pull the new lockfile and restart next dev.

Why it matters

A single "next is vulnerable" alert hides six very different stories. A static marketing site on Vercel with no remote images may be affected by none of these. A self-hosted Pages Router app with ISR and a root catch-all is in the path of a cross-user content bug that one unauthenticated request can trigger.

The fix is the same upgrade in both cases, but the urgency isn't. Teams that can answer "do we use this feature" quickly can patch the reachable cases today and batch the rest into the next routine bump.

Try it yourself

Copy the table above into your ticket and add a column called "Uses it?". Fill it in for one production app using the grep commands. Count how many of the six rows you can mark "no". That count is the difference between version matching and reachability.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Next.js v16.3.8 release notes
• Next.js v15.5.27 release notes
• GHSA-cjq9-62q9-8jv4: SSRF in Image Optimization
• GHSA-4jqv-mc3x-m676: SSG/ISR cache poisoning in self-hosted apps
• GHSA-mcj8-r9mp-w47p: SSG/ISR cache poisoning via catch-all
• GHSA-3w37-wq28-93x7: Draft Mode content leak
• GHSA-f87g-xv8r-7p7x: metadata image routes dynamicParams bypass
• GHSA-39w2-rjm5-chcv: dev server MCP endpoint