Next.js Image Cache Leak Can Expose Private Images to Wrong Users

Vulnerability Explanation

The Next.js Image Optimization pipeline contains a cache key confusion bug in the `fetchInternalImage` function (`packages/next/src/server/image-optimizer.ts`). When an internal API route is used as an image source, the optimizer forwards the incoming request's headers (e.g., `Cookie`, `Authorization`) to the API route, allowing the route to generate user-specific image content. However, the resulting optimized image is stored in the cache using a key derived only from image parameters (URL, width, quality, MIME type) — not from the request headers that influenced the image content. This means the first authenticated user to request a protected image populates the cache, and subsequent unauthenticated or differently-authenticated users receive that same cached image without needing valid credentials.

Root Cause

The cache key for optimized images was computed from image-level parameters only (URL, width, quality, MIME type), without accounting for request headers that the upstream API route used to produce user-specific content. This mismatch between cache key scope and content variation scope is a classic cache deception pattern (CWE-524).

Technical Impact

An unauthenticated or differently-authenticated user can receive image content intended for another user. This enables unauthorized disclosure of user-specific or protected image content, and cross-user leakage of conditional content via CDN or internal application cache. No elevated privileges or user interaction are required beyond a prior authorized request having populated the cache.

Severity Justification

Exploitability is conditional: the vulnerability only manifests when API routes serve header-dependent images through Next.js Image Optimization. No active exploitation or user interaction is required once the cache is primed, but the attack surface is limited to apps with this specific architecture. GitHub Advisory rates this as Moderate severity.

Affected Components

• next >= 0.9.9, < 14.2.31
• next >= 15.0.0, < 15.4.5

Remediation Steps

1. Identify your current Next.js version by running `npm list next` or checking `package.json`.
2. If on the 14.x line, upgrade to 14.2.31: `npm install next@14.2.31` (or `yarn add next@14.2.31`).
3. If on the 15.x line, upgrade to 15.4.5: `npm install next@15.4.5` (or `yarn add next@15.4.5`).
4. If on Next.js 13 or older (end-of-life), plan a migration to v14 or v15. As an interim workaround, avoid serving header-dependent images through Next.js Image Optimization — serve them directly from your API route without using the `<Image>` component or `/_next/image` endpoint.
5. Rebuild and redeploy your application. Clear any existing image optimization cache (delete the `.next/cache/images` directory) to purge any potentially leaked cached images.
6. Verify the fix by checking `npm list next` in production and confirming the version is 14.2.31+ or 15.4.5+.

Verification Steps

1. Run `npm list next` or `cat package.json | grep '"next"'` to confirm the installed version.
2. Check the running version in production via `/_next/static/chunks/` build manifests or your deployment platform's dependency view.
3. If you have header-dependent image routes, test that a request without valid auth credentials does not return a previously cached authenticated image (e.g., use `curl` with and without a valid session cookie against a `/_next/image?url=...` endpoint).
4. Confirm `.next/cache/images` has been cleared and repopulated post-deploy.

Code Examples (json)

// package.json — vulnerable version
{
  "dependencies": {
    "next": "12.3.1"
  }
}

// package.json — patched version (14.x line)
{
  "dependencies": {
    "next": "14.2.31"
  }
}

// Or for the 15.x line:
{
  "dependencies": {
    "next": "15.4.5"
  }
}

Best Practices

• Never use Next.js Image Optimization (the `<Image>` component or `/_next/image` endpoint) to serve images whose content varies by user session or authorization state — serve those directly from your API with proper cache-control headers (`Cache-Control: private, no-store`).
• When building image-serving API routes that depend on auth headers, explicitly set `Cache-Control: private, no-store` on the response to prevent any intermediate cache from storing the result.
• Pin your Next.js version in `package.json` and use a dependency audit tool (e.g., `npm audit`, Dependabot, or Snyk) to receive automated alerts for future security patches.
• After any security-related upgrade, clear your application's image cache directory (`.next/cache/images`) before redeploying to ensure stale cached content is not served.

References

• github.com/advisories/GHSA-g5qg-72qw-gw5v
• vercel.com/changelog/cve-2025-57752
• github.com/vercel/next.js/security/advisories/GHSA-g5qg-72qw-gw5v