Next.js security: the CVEs, defaults and holes to check in your app

Is Next.js secure? What it protects and what it leaves to you

Next.js is the React framework maintained by Vercel. One codebase holds your pages, your API routes (Route Handlers), your Server Actions and the code that talks to your database, so a Next.js app is a server, not only a website. Everything that depends on your data model stays your job: who owns which record, and which page needs a login. And the framework itself has had serious vulnerabilities, which only an upgrade fixes.

Here is the split, checked against the Next.js documentation in November 2026:

Where you host changes a few of these. On Vercel, routing runs in a separate system, which is why the 2025 middleware bypass never reached apps hosted there. For React2Shell, Vercel designed firewall rules with the React team before the CVE was announced and deployed them to all its users. Neither replaces the upgrade: Vercel's own bulletin says WAF rules cannot block every variant and tells everyone to check their versions directly.

The Next.js vulnerabilities that matter, 2024 to November 2026

Most of them hit a place where an app trusts the framework to draw a line: proxy auth, Server Actions, the image optimizer or the cache. In 2026 alone, the GitHub Advisory Database lists five critical remote code execution advisories for next, three of them in image processing. The table lists the ones to know, with the affected and fixed versions from each advisory.

How to check which Next.js version you run

1. 1

   Read the installed version, not the range

   package.json may say ^15.2.0; the lockfile decides what ships. Run npm ls next react react-dom (or pnpm why next, yarn why next) in the project.

2. 2

   Compare it to the current floor

   The 3 November 2026 security release is 16.4.5 for the 16.x line (Active LTS) and 15.5.29 for 15.x (Maintenance LTS). The Next.js support policy asks you to serve production from the latest release of one of those two lines, so a 14.x or older app needs a major upgrade, not a patch. Security releases for 15.x are promised only through 31 January 2027, so plan the move to 16.

3. 3

   Upgrade and deploy from the lockfile

   Run npm install [email protected] (or [email protected]), commit the lockfile, and make sure your host installs with npm ci or the equivalent, so the version you tested is the version that runs.

4. 4

   Hear about the next release first

   Next.js usually announces security releases on its blog a week ahead, but it moved the August 2026 one forward for a new critical flaw. Watch the security advisories of the vercel/next.js repository on GitHub.

# What is installed, including nested copies
npm ls next react react-dom

# The image library Next.js uses: 0.35.5 or later (October 2026 SVG advisory)
npm ls sharp

# Upgrade to the November 2026 security release (pick your line)
npm install [email protected]
npm install [email protected]

# Known advisories in your production dependencies
npm audit --omit=dev

Next.js middleware auth: why proxy is not enough

Next.js 16 renamed middleware to proxy: the file is now proxy.ts, it exports a proxy function and it runs on the Node.js runtime by default. The middleware.ts convention is deprecated. Either way, the Next.js authentication guide calls a check there optimistic: read the session cookie and redirect, without database queries, because proxy runs on every route, prefetches included. The secure check, against your session store, belongs where the data is read.

Two CVEs show why. CVE-2025-29927 let a request skip middleware with one header. CVE-2026-44575 let App Router requests reach a protected page through URL variants the matcher did not cover, and its advisory gives the lesson as a workaround: enforce authorization in the route or page itself instead of relying on middleware alone. They were not the only ones: in May and July 2026, GitHub published four more middleware or proxy bypass advisories for next, through i18n, dynamic route parameters, Turbopack with a single locale, and the incomplete first fix of CVE-2026-44575. Apps that already checked the user next to the data had nothing behind any of these bypasses.

// proxy.ts: fine as a first filter, wrong as the only one
import { NextResponse, type NextRequest } from 'next/server'

export function proxy(request: NextRequest) {
  if (!request.cookies.get('session')) {
    return NextResponse.redirect(new URL('/login', request.url))
  }
}

export const config = { matcher: ['/dashboard/:path*'] }

// lib/dal.ts: the check that counts, next to the data
import 'server-only'
import { cache } from 'react'
import { redirect } from 'next/navigation'
import { getSession } from '@/lib/session' // your auth library

export const requireUser = cache(async () => {
  const session = await getSession() // verified against your session store
  if (!session) redirect('/login')
  return session
})

// app/dashboard/invoices/page.tsx
import { requireUser } from '@/lib/dal'
import { db } from '@/lib/db'
import { InvoiceList } from './invoice-list'

export default async function InvoicesPage() {
  const { userId } = await requireUser()
  const invoices = await db.invoice.findMany({ where: { ownerId: userId } })
  return <InvoiceList invoices={invoices} />
}

Server Actions are public endpoints

A Server Action looks like a function call in your component. On the network it is a POST to your app that anyone can send. The Next.js data security guide says it plainly: an exported Server Action is reachable by a direct POST request, even if no screen of your app uses it, and a login check on a page does not extend to the actions defined in it. Next.js encrypts action ids and removes unused actions from the client bundle, which helps when a check is missing, but the ids of the actions your pages call ship in the JavaScript every visitor downloads.

So every action needs two checks: authentication (is someone signed in?) and authorization (may this user touch this record?). Skipping the second is an IDOR: change the id in the request, get or delete someone else's data.

'use server'
import { z } from 'zod'
import { requireUser } from '@/lib/dal'
import { db } from '@/lib/db'

// Bad: anyone who sends this action an id deletes that invoice
export async function deleteInvoiceUnsafe(id: string) {
  await db.invoice.delete({ where: { id } })
}

// Good: validate the input, check the caller, scope the query to their rows
export async function deleteInvoice(input: unknown) {
  const id = z.string().uuid().parse(input)
  const { userId } = await requireUser()
  const { count } = await db.invoice.deleteMany({ where: { id, ownerId: userId } })
  if (count === 0) throw new Error('Not found')
  return { ok: true } // return what the UI needs, never the raw row
}

Against cross-site requests the defaults are good: actions only accept POST, and Next.js aborts the request when the Origin header does not match the host (or X-Forwarded-Host). CVE-2026-27978 was the gap: Next.js treated Origin: null, which sandboxed iframes send, as a missing origin and let it through until 16.1.7. Never add 'null' to experimental.serverActions.allowedOrigins, list only your own domains there if you run behind a reverse proxy, and set SameSite=Strict on sensitive auth cookies, as the advisory suggests.

Secrets: NEXT_PUBLIC_, source maps and server-only code

Next.js copies the value of every variable whose name starts with NEXT_PUBLIC_ into the JavaScript at build time. The name is the only switch. When a Client Component cannot read a variable, adding the prefix makes the error go away, and that is how secret keys end up in bundles. Public is fine for keys designed to be public. Anything else is readable by every visitor from the first deploy, see API keys exposed in the frontend.

To check, build the app and search what the browser receives, not your source:

npm run build

# Every public variable your code references
grep -rhoE "NEXT_PUBLIC_[A-Z0-9_]+" app src lib components 2>/dev/null | sort -u

# Secret key formats in the files sent to browsers
grep -rlE "sk_live_|sk-proj-|sk-ant-|sb_secret_|whsec_|PRIVATE KEY" .next/static

Two related leaks. Production source maps are off by default, and productionBrowserSourceMaps: true makes Next.js serve your original source next to each JavaScript file, comments and internal routes included. And everything in the public/ folder is served at your site's root, so a .env file or a database export copied there is one URL away, see exposed .env files. Mark the modules that hold secrets or database access with import 'server-only', so importing one from a Client Component fails the build instead of shipping the code.

Next.js security headers

Out of the box, Next.js adds an X-Powered-By header that tells everyone what you run; poweredByHeader: false removes it. The protective headers are left to you, and the Next.js docs show how to set them. The simplest place is headers() in next.config.ts:

// next.config.ts
import type { NextConfig } from 'next'

const securityHeaders = [
  { key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubDomains; preload' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
  { key: 'Content-Security-Policy', value: "frame-ancestors 'self'; base-uri 'self'; object-src 'none'" },
]

const nextConfig: NextConfig = {
  poweredByHeader: false,
  async headers() {
    return [{ source: '/:path*', headers: securityHeaders }]
  },
}

export default nextConfig

A strict Content-Security-Policy for scripts needs a nonce: a random value, new on every request, that marks your own inline scripts as allowed. Next.js can generate it in proxy, but its docs say a page must be rendered dynamically to get a nonce, so the pages that use one cannot be static. If that cost is too high, ship the partial policy above first, and try a script policy in Content-Security-Policy-Report-Only before you enforce it. The security headers guide has the full nonce setup and the report-only rollout, with config for Vercel, Netlify and Cloudflare.

The image optimizer and the cache: quieter leaks

/_next/image fetches remote images from your server. Next.js only lets it fetch hosts that match images.remotePatterns and answers 400 to the rest, and since version 16 it refuses addresses on your local network unless you set dangerouslyAllowLocalIP: true. Three things weaken it: broad wildcards; redirects, which the optimizer follows up to 3 times by default without checking the new location against your patterns; and allowed hosts whose DNS someone else controls, the case behind CVE-2026-94483. Pin the list:

// next.config.ts, inside nextConfig
images: {
  remotePatterns: [new URL('https://YOUR_PROJECT.supabase.co/storage/v1/object/public/avatars/**')],
  maximumRedirects: 0,
},

The optimizer also decodes whatever image it is given, and decoders are written in C. In August 2026 a flaw in libheif, which sharp uses for AVIF, allowed code execution through an attacker-controlled AVIF image, so the patched releases turned AVIF optimization off. In October 2026 a memory flaw in an upstream image library did the same with SVG files on glibc-based Linux. The fix for both is the upgrade, and for the SVG flaw on 15.x it is not enough on its own: 15.5.28 still accepts sharp 0.34, so run npm ls sharp and make sure it shows 0.35.5 or later. The GHSA-2464-fhr4-w9xw page has the commands.

Caching is the other quiet one. A page or Route Handler that returns one user's data must never be stored where the next visitor gets it, whether by use cache, unstable_cache or a CDN in front of the app. Three advisories in the November 2026 release were exactly this: with Cache Components, a result computed for one tenant or user could be served to another. After upgrading, keep per-user data out of shared caches and send Cache-Control: private, no-store on authenticated responses.

What Keybrum tests on a live Next.js app

The checks above read your code. Keybrum reads your deployed app from the outside, the way a stranger would, and keeps a finding only when the behavior is proven: a CVE is never reported from a version number alone. It only attacks apps whose owner proved ownership.

Each finding comes with the request that worked and a fix your coding agent reads through Keybrum's MCP server. After the fix, the same attack runs again.

Prompts to give your coding agent

If Cursor, Claude Code or another agent wrote your app, give it these one at a time and read the diff before you merge:

1. Upgrade next to 16.4.5 (or 15.5.29 if we stay on 15), update react and react-dom to the versions it expects, run the build and the tests, and commit the lockfile.

2. List every exported Server Action and Route Handler. For each one, show where it checks the session and where it checks that the record belongs to the caller. Add both where missing, through one requireUser() helper in lib/dal.ts marked with import 'server-only'.

3. Keep proxy.ts as an optimistic redirect only. Every page that reads private data must call requireUser() itself.

4. List every NEXT_PUBLIC_ variable and say whether its value is meant to be public. Move any secret to a server-only variable and call the provider from the server.

5. Add security headers in next.config.ts (Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, a CSP with frame-ancestors), set poweredByHeader: false, and confirm productionBrowserSourceMaps is not enabled.

6. Restrict images.remotePatterns to exact hosts and paths, and set images.maximumRedirects to 0.

Next.js security checklist

• Next.js 16.4.5 or 15.5.29 or later, confirmed with npm ls next and in the deployed build, and sharp 0.35.5 or later
• Every Server Action and Route Handler checks the session and the record's owner
• Proxy (or middleware) only does optimistic redirects; pages check the user themselves
• No secret behind NEXT_PUBLIC_, and no secret key format in .next/static
• productionBrowserSourceMaps off, nothing private in public/
• Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy and a CSP with frame-ancestors sent; X-Powered-By removed
• images.remotePatterns lists exact hosts, maximumRedirects set
• Per-user responses never stored in a shared cache
• experimental.serverActions.allowedOrigins lists only your domains, never 'null'
• Security advisories of vercel/next.js watched on GitHub
• On Supabase: RLS on every table, see the Supabase RLS guide

For the parts outside Next.js, the vibe coding security checklist covers the database, payments and AI endpoints, and vibe coding security risks explains where generated apps usually break.