Outdated Next.js Version Exposes Server to Unauthorized Internal Requests

Vulnerability Explanation

In Next.js versions prior to 14.2.32 and 15.4.7, the middleware layer contained a flaw in how it processed responses that included a `Location` header. Before the patch, any middleware response containing a `Location` header was unconditionally treated as a redirect, causing the server to attempt to fetch the URL specified in that header. Because request headers could be passed directly into `NextResponse.next()` without sanitization, an attacker could craft a request with a malicious `Location` header value, causing the Next.js server to issue an unintended internal request — a classic Server-Side Request Forgery (SSRF) pattern. The vulnerable code path was in `getResolveRoutes` within `packages/next/src/server/lib/router-utils/resolve-routes.ts`. The fix adds a check to ensure the response status code is a valid redirect status before treating the `Location` header as a redirect target.

Root Cause

The `getResolveRoutes` function did not validate that a redirect status code was present before acting on a `Location` response header. Combined with middleware patterns that forwarded raw incoming request headers into `NextResponse.next()`, this allowed user-controlled header values to influence server-side routing decisions.

Technical Impact

An unauthenticated remote attacker can craft HTTP requests with a malicious `Location` header that, when reflected through vulnerable middleware into `NextResponse.next()`, causes the Next.js server to make outbound requests to attacker-specified internal or external URLs. This can result in: access to internal-only services (metadata endpoints, databases, admin APIs), network reconnaissance behind a firewall, and potential data exfiltration. Exploitation requires the application to have custom middleware that forwards request headers without sanitization and to be running in a self-hosted (non-Vercel-managed) environment.

Severity Justification

Network-accessible with no authentication required, but exploitation depends on a specific middleware implementation pattern (direct header forwarding into NextResponse.next()). Not universally exploitable across all Next.js deployments. CVSS 6.5 aligns with the official GitHub Advisory classification of 'Moderate'.

Affected Components

• next (npm) >= 0.9.9, < 14.2.32
• next (npm) >= 15.0.0-canary.0, < 15.4.7

Remediation Steps

1. Upgrade Next.js to 14.2.32 (for v14 users) or 15.4.7 (for v15 users): `npm install next@14.2.32` or `npm install next@15.4.7`.
2. Audit all `middleware.ts` / `middleware.js` files for patterns that pass raw request headers into `NextResponse.next()`. Replace them with the explicit safe form.
3. Ensure the `Location` header and other sensitive routing headers are never forwarded from client requests to `NextResponse.next()` without validation.
4. After upgrading, redeploy the application and verify the running version matches the patched release.

Verification Steps

1. Run `npm list next` or check `package.json` to confirm the installed version is >= 14.2.32 or >= 15.4.7.
2. Review all middleware files for `NextResponse.next({ request: { headers: ... } })` patterns and confirm no raw `request.headers` are passed through without sanitization.
3. Send a test request with a crafted `Location` header to a middleware-protected route and confirm the server does not follow the redirect to an internal address.
4. Check application logs post-deployment for any anomalous outbound requests to internal IP ranges.

Code Examples (typescript)

// middleware.ts — VULNERABLE: raw request headers forwarded into NextResponse.next()
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  // Dangerous: forwards all incoming headers, including attacker-controlled ones
  return NextResponse.next({
    request: {
      headers: request.headers, // ← passes Location and other sensitive headers through
    },
  });
}

// middleware.ts — FIXED: explicitly construct only the headers you need
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  // Safe: pass the request object directly, or build a clean headers object
  return NextResponse.next({ request });
  // OR, if you need to add/modify specific headers:
  // const requestHeaders = new Headers(request.headers);
  // requestHeaders.delete('location'); // strip sensitive headers explicitly
  // return NextResponse.next({ request: { headers: requestHeaders } });
}

Best Practices

• Never forward raw, unvalidated client request headers to internal routing functions — always construct an explicit, allowlisted set of headers.
• Treat any header that influences server-side routing (e.g., `Location`, `X-Middleware-Rewrite`) as untrusted input and strip or validate it before use.
• Keep framework dependencies pinned to a minor version range and subscribe to the framework's security advisory feed (GitHub Advisories for `vercel/next.js`).
• In self-hosted environments, apply network egress controls to limit which internal addresses your Next.js process can reach, reducing SSRF blast radius.

References

• github.com/advisories/GHSA-4342-x723-ch2f
• vercel.com/changelog/cve-2025-57822
• github.com/vercel/next.js/commit/9c9aaed5bb9338ef31b0517ccf0ab4414f2093d8
• github.com/vercel/next.js/security/advisories/GHSA-4342-x723-ch2f