CVE-2025-57752

What it actually does

This is an information disclosure flaw in Next.js Image Optimization caused by cache key confusion. If an application uses API routes to generate or return images whose content varies based on request headers such as Cookie or Authorization, the image optimizer may cache a response without correctly including those authorization-sensitive request attributes in the cache key. As a result, an image generated for one authenticated or authorized requester can later be served from cache to another requester who should not have access to that image. The issue affects confidentiality only; it does not directly provide code execution, authentication bypass for non-image resources, or data modification capability.

Why it matters to the business

Applications that use Next.js image optimization for personalized, private, account-specific, or entitlement-controlled images may unintentionally expose those images to other users. Potential consequences include privacy incidents, leakage of customer or employee data embedded in images, regulatory notification obligations depending on the data exposed, reputational harm, and loss of trust in access controls. The currently reported exploitation maturity is none, EPSS is low, and it is not listed in CISA KEV, but the issue is straightforward to trigger where vulnerable routing patterns exist and has been public for a long period, so internet-facing applications should still remediate promptly.

How an attack unfolds

An attacker first identifies a Next.js application using the built-in Image Optimization endpoint, commonly through requests to /_next/image. They then look for optimized image URLs that reference application API routes rather than static public images. If those API routes return different image content based on Cookie, Authorization, or other request headers, the attacker attempts to influence or observe cache behavior. In a typical scenario, an authorized user requests a protected image through the optimizer, causing the private response to be stored in the image optimization cache under an insufficiently specific key. The attacker then requests the same optimized image URL without the same authorization context. Because the vulnerable cache key does not fully distinguish the authenticated response variant, the optimizer may return the cached private image to the unauthorized requester. Successful exploitation depends on the application serving header-dependent images through API routes with image optimization enabled and reachable by the attacker.

How to fix it

Upgrade Next.js to a fixed release: 15.4.5 or later for the 15.x line, or 14.2.31 or later for the 14.x line. The upstream git fix is identified as commit b9aab5dbe926c256d439bfecb226693dcd1a1be4. After upgrading, rebuild and redeploy the application so the fixed image optimizer code is active. Purge image optimization caches, CDN caches, reverse proxy caches, and any platform-level edge caches that may contain previously cached private images. As a mitigation if immediate upgrade is not possible, avoid serving authorization-dependent or personalized images through Next.js Image Optimization; exclude those routes from optimization, mark private image responses as non-cacheable, use unoptimized image delivery for sensitive content, or redesign image URLs so the cache key contains a non-shared, authorization-safe identifier. Ensure API routes returning private images set conservative cache headers such as Cache-Control: private, no-store where appropriate.

How to confirm the fix worked

Confirm the deployed Next.js version is 15.4.5 or later, or 14.2.31 or later, and verify the running artifact was rebuilt after the dependency update. Review package manifests, lockfiles, container images, and software composition analysis results for vulnerable Next.js versions. Functionally test representative private image API routes by requesting an optimized image as one authorized user, then repeating the same optimized image request without credentials and as a different user; the second requester must not receive the first user's image. Inspect response headers and cache behavior to ensure sensitive image responses are not reused across authorization contexts. Clear caches before and after validation to distinguish stale cached content from fixed runtime behavior. If CDN or reverse proxy caching is present, validate both direct application responses and externally cached responses.

Typical attack path

1. Fingerprint a target application as running Next.js and using Image Optimization, often by observing /_next/image requests.
2. Identify optimized image URLs whose url parameter points to an application API route or other dynamic image-producing endpoint.
3. Determine whether the image content varies based on Cookie, Authorization, or similar request headers.
4. Cause or wait for an authorized request to populate the image optimization cache with private or user-specific image content.
5. Send an unauthenticated or differently authenticated request for the same optimized image URL.
6. Inspect whether the response is served from cache and contains image content belonging to another user or authorization context.

How to detect it

To investigate prior exploitation, analyze web server, application, CDN, edge cache, and reverse proxy logs for Image Optimization requests to /_next/image where the url parameter references API routes or dynamic image endpoints. Focus on sequences where the same optimized image URL was requested first with Cookie or Authorization headers and later without those headers, or by a different authenticated principal, and where the later response was a cache hit or returned the same response size/content hash. Review logs for x-nextjs-cache, CDN cache status, age, etag, content-length, request headers, user agent, source IP, authenticated user/session metadata if logged, and normalized URL including query string. Compare requests for protected image routes against authorization decisions in application logs; a suspicious pattern is a successful 200 image response from cache without a corresponding successful authorization check for that requester. If image cache files or CDN objects are available, sample cached objects for sensitive content and correlate object creation time with access logs. Because exploitation does not require a distinctive payload and may look like normal image browsing, detection is primarily behavioral and correlation-based rather than signature-based.

• GET /_next/image
• /_next/image?url=%2Fapi%2F
• /_next/image?url=/api/
• x-nextjs-cache: HIT
• x-vercel-cache: HIT
• cf-cache-status: HIT
• x-cache: HIT
• Authorization: Bearer
• Cookie:
• Cache-Control: private
• Cache-Control: no-store

What your security team should do

• Inventory Next.js applications that use Image Optimization and prioritize those exposing /_next/image on the internet.
• Identify API routes or dynamic image endpoints whose output depends on Cookie, Authorization, session state, user identity, tenant, role, or entitlement headers.
• Upgrade affected applications to Next.js 15.4.5+ or 14.2.31+ and redeploy from a clean build.
• Purge all relevant application, image optimizer, CDN, reverse proxy, and edge caches after patching.
• Temporarily disable optimization for private or personalized images until the fixed version is deployed and validated.
• Add regression tests that verify protected images are not served to unauthenticated or differently authenticated users via the optimizer.
• Review web access logs for suspicious repeated /_next/image requests against dynamic API image URLs, especially requests alternating between authenticated and unauthenticated contexts.
• Treat confirmed leakage of sensitive images as a data exposure incident and follow privacy, legal, and customer notification procedures as applicable.