CVE-2026-94483: the Next.js image optimizer SSRF, who is affected and how to fix it

What CVE-2026-94483 is, in plain words

When a page shows a remote picture with next/image, the browser asks your own server for /_next/image?url=..., and the Next.js image optimizer fetches the original, resizes it and serves a smaller copy. A server that fetches URLs on request is the classic target for server-side request forgery (SSRF): getting a server to send requests for you, to places you cannot reach yourself, such as its private network.

Next.js has two guards. The first is the allow-list in images.remotePatterns: a URL that matches no pattern gets 400 Bad Request with the text "url" parameter is not allowed. The second arrived in 16.0.0: the optimizer refuses images from local and private IP addresses unless you set images.dangerouslyAllowLocalIP: true, which the Next.js docs advise against for most users because it could let malicious users reach content on your internal network.

CVE-2026-94483 gets around the second guard. Per the advisory, from 16.0.0 until 16.3.8 the optimizer "can follow attacker-controlled DNS resolution" for a URL that matches remotePatterns, so the fetch reaches a private IP address after the URL has passed the checks. CyCognito's analysis explains the mechanism: the check and the fetch looked up the hostname separately, so a hostname whose DNS the attacker controls can answer the check with a public address and the fetch with an internal one, a trick called DNS rebinding. The fix, a commit titled "Pin DNS resolution when fetching external images", connects to the address that passed the check instead of looking the name up a second time.

Severity and exploitation status

The two official scores differ because they use different CVSS versions. The facts box uses the score of the CNA, the organisation that assigned the CVE: GitHub, for the Next.js advisory.

The high complexity is the precondition: control of DNS for a hostname your allow-list accepts. Your patterns decide how hard that is, so the next section matters more than the score. We found no public report of exploitation, but a proof of concept is listed in public, so treat the technique as known.

Who is affected

Your app is exposed when all four of these are true:

1. It runs next 16.0.0 to 16.3.7.
2. images.remotePatterns is set in next.config. The advisory is explicit: apps without it are not affected.
3. Your own Next.js server runs the optimizer: next start, the standalone output in a Docker image, or any Node server you host.
4. At least one allowed hostname has DNS that someone other than you can set or change.

The fourth point is where allow-lists differ. A pattern for your own domain, or a storage host your provider runs, is hard to abuse. A pattern that accepts any host lets anyone who owns a domain meet the precondition, and a wildcard such as **.some-platform.app does the same wherever strangers can create subdomains. The Next.js docs also warn that leaving out protocol, port, pathname or search implies the wildcard **, which "may allow malicious actors to optimize urls you did not intend".

What a stranger gains is a request sent from inside your network: internal admin panels, services listening on a private address, cloud metadata endpoints such as 169.254.169.254. How much of the answer comes back depends on the target; the CNA rates the confidentiality impact high and the integrity impact low. The Next.js security guide covers the other server settings worth reviewing.

How to check your Next.js version

Check the version your lockfile resolves, not the range in package.json: "next": "^16.3.0" can install any 16.x from 16.3.0 up. Run one of these at the root of the project:

# What is installed
npm ls next
pnpm why next
yarn why next

# The Next.js CLI prints its own version
npx next --version

# Straight from the lockfile
grep -A2 '"node_modules/next"' package-lock.json
grep -E "^  '?next@" pnpm-lock.yaml
grep -A1 -E '^"?next@' yarn.lock

In a monorepo, check every app: each can resolve its own copy of next. npm audit and Dependabot report it as GHSA-cjq9-62q9-8jv4.

How to check your image config and your live app

Start with the allow-list itself:

grep -rn -A8 -E "remotePatterns|domains|dangerouslyAllowLocalIP" next.config.*

For each entry, ask who controls that hostname's DNS. Your own domain, or a storage host your provider runs, such as YOUR_PROJECT_REF.supabase.co for Supabase Storage, is fine. A pattern that accepts any host, a wildcard over a shared platform, or a domain you might let expire should go or be narrowed. The advisory does not mention the deprecated domains list, so if you still use it, move to exact remotePatterns.

Then confirm the deployed app enforces the allow-list. Run this against your own app only:

# Control: an image your allow-list accepts. Expect 200.
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://YOUR_APP/_next/image?url=https%3A%2F%2FYOUR_IMAGE_HOST%2Fpath%2Fimage.png&w=64&q=75"

# Probe: a host you never allowed. Expect the text: "url" parameter is not allowed
curl -s -w "\n%{http_code}\n" \
  "https://YOUR_APP/_next/image?url=https%3A%2F%2Fexample.com%2Fimage.png&w=64&q=75"

This proves the allow-list works. It does not test the DNS trick itself, which is not something to try on a production server: your version number answers that half.

Keybrum's attack web.nextjs-image-ssrf runs the live half on apps whose owner proved ownership. It is an out-of-band check: it asks /_next/image to optimize a unique URL on Keybrum's public callback server, then watches whether your server calls it. A hit proves your allow-list accepts a host that a stranger controls, which is this CVE's precondition. It never requests an internal address and does not try the DNS trick. A finding comes with the request that worked and the fix, which your coding agent reads through Keybrum's MCP server.

How to fix CVE-2026-94483

1. 1

   Upgrade Next.js

   16.3.8 is the first fixed release. Go to the latest 16.x instead, 16.4.5 at the time of writing, which also carries the November 2026 security release: npm install [email protected], pnpm add [email protected], yarn add [email protected] or bun add [email protected].

2. 2

   Commit the lockfile and redeploy

   The fix reaches production only through the lockfile. If you ship a Docker image, make sure the install step does not come from a stale build cache.

3. 3

   Narrow images.remotePatterns

   List the exact hosts and paths you serve images from. Remove patterns that accept any host, and wildcards over platforms where strangers can create subdomains.

4. 4

   Block what the server never needs to reach

   At the firewall or security group, stop the app server from connecting to 169.254.169.254 and to private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), except the internal hosts it uses, such as your database. That limits every SSRF.

// Before: any host, plus a wildcard over a shared platform
images: {
  remotePatterns: [
    { protocol: 'https', hostname: '**' },
    { protocol: 'https', hostname: '**.some-platform.app' },
  ],
},

// After: only the hosts and paths you serve images from
images: {
  remotePatterns: [
    {
      protocol: 'https',
      hostname: 'YOUR_PROJECT_REF.supabase.co',
      pathname: '/storage/v1/object/public/**',
      search: '',
    },
    new URL('https://cdn.your-domain.com/images/**'),
  ],
},

What to do after upgrading

• npm ls next, or the pnpm or yarn equivalent, shows 16.3.8 or later for every app in the repository.
• The deployed build was rebuilt from the new lockfile, not served from a cached image.
• The control request above still returns 200, and the probe still answers "url" parameter is not allowed.
• images.remotePatterns lists exact hosts, and dangerouslyAllowLocalIP is absent or false outside local development.
• Server or proxy logs for /_next/image show no url= hosts you do not recognise. If they do and the server holds cloud credentials, rotate them.

The same 16.3.8 release also patched cache poisoning and information disclosure advisories, so the upgrade is worth it even without remotePatterns.

Related Next.js CVEs

• CVE-2024-34351: the earlier Next.js SSRF, in Server Actions, where a forged Host header steered a server-side fetch. Fixed in 14.1.1.
• CVE-2025-29927: the middleware bypass through the internal x-middleware-subrequest header.
• CVE-2026-44575: a middleware bypass through .rsc and segment-prefetch URLs.
• CVE-2026-27978: Server Actions accepting cross-site calls sent with Origin: null.
• CVE-2026-94543 and CVE-2026-94484: cache poisoning of SSG and ISR pages, fixed the same day in 16.3.8 and, for 15.x, in 15.5.27.

If a coding agent wrote your next.config, review its allow-lists too: the security risks of vibe-coded apps covers the rest.

Timeline