CVE-2025-59471

What it actually does

This is an availability flaw in self-hosted Next.js applications using the Image Optimizer with images.remotePatterns configured for external image sources. The /_next/image endpoint can fetch an attacker-controlled or attacker-influenced external image and load the image content into process memory without enforcing a maximum image size limit. A sufficiently large image, or repeated requests for large images, can exhaust Node.js memory, trigger out-of-memory errors, crash the application process, or cause container restarts and elevated 5xx responses. The issue does not provide confidentiality or integrity impact, and exploitation depends on the attacker being able to serve or control a large image from a domain allowed by the application's remotePatterns configuration.

Why it matters to the business

Successful exploitation can make affected web applications slow, unstable, or unavailable, especially for self-hosted deployments with limited container or server memory. Public-facing applications may experience downtime, failed page loads, increased autoscaling or hosting costs, degraded customer experience, and operational alerts caused by repeated crashes or restarts. The EPSS score is low and the vulnerability is not listed in CISA KEV, but the endpoint is commonly internet-facing in Next.js applications, so exposed systems with permissive remotePatterns should still be prioritized for upgrade or mitigation.

How an attack unfolds

An attacker first identifies a self-hosted Next.js application exposing the Image Optimizer endpoint at /_next/image. They then determine whether the application accepts external image URLs through its configured remotePatterns. If the attacker controls an allowed domain, can upload content to an allowed domain, or can otherwise place a very large image at an allowed URL, they craft requests to /_next/image using the large external image as the url parameter, along with accepted width and quality parameters. The vulnerable optimizer fetches the external image and loads it into memory without a sufficient maximum size check. One or more requests can consume enough memory to degrade performance, force garbage collection pressure, trigger JavaScript heap or native out-of-memory failures, and crash the Next.js process. Repeating the requests can keep the service in a degraded or unavailable state even when supervisors, orchestration platforms, or process managers restart it.

How to fix it

Upgrade affected self-hosted Next.js applications to a fixed release. The advisory specifically recommends upgrading to Next.js 15.5.10 or 16.1.5, or applying the upstream fix corresponding to vercel/next.js commit 60a2aa97b6692d3a56e483f0ff93febaf6f33fd6 where source-based remediation is used. Review package manifests and lockfiles to ensure the deployed application is actually using the fixed Next.js version. As defense in depth, restrict images.remotePatterns to the smallest necessary set of trusted hosts, avoid wildcard or overly broad external domains, remove external image optimization where it is not required, and ensure untrusted users cannot upload arbitrary large files to allowed image domains. Add reverse proxy, CDN, or WAF controls to rate-limit /_next/image requests, limit request concurrency, and monitor outbound fetch volume. Enforce container memory limits and restart policies, but do not rely on restarts as the primary mitigation because repeated requests can cause recurring outages.

How to confirm the fix worked

Confirm the application is no longer running an affected Next.js build by checking package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, build metadata, or runtime dependency output such as npm ls next. Verify the deployed version is 15.5.10, 16.1.5, or includes upstream commit 60a2aa97b6692d3a56e483f0ff93febaf6f33fd6. Review next.config.js or next.config.mjs for images.remotePatterns and confirm only required trusted domains are allowed. Inspect the running service to confirm /_next/image still behaves as expected for legitimate images. In a controlled non-production environment, test image optimization with bounded-size images while monitoring memory; patched or mitigated deployments should not show unbounded memory growth from oversized remote images. Validate proxy, CDN, or WAF rate limits and alerting for excessive /_next/image traffic.

Typical attack path

1. Identify a public self-hosted Next.js application exposing the /_next/image optimization endpoint.
2. Probe the endpoint with external image URLs to determine whether remote image optimization is enabled and which external domains are accepted.
3. Host, upload, or reference an unusually large image on a domain allowed by the application's remotePatterns configuration.
4. Send crafted requests to /_next/image with the large image URL in the url parameter and valid width and quality values.
5. Repeat or parallelize requests to drive memory consumption above the Node.js process, container, or host limit.
6. Cause application crashes, container restarts, high latency, or sustained HTTP 5xx errors.

How to detect it

To assess prior exploitation, correlate web access logs, CDN logs, reverse proxy logs, application logs, container or host telemetry, and outbound network logs. Look for bursts of requests to /_next/image with url parameters pointing to external domains, especially immediately before memory spikes, process crashes, container OOM kills, restarts, elevated latency, or 502/503/504 responses. Review whether requested image URLs belong to domains allowed by images.remotePatterns and whether those URLs correspond to unusually large objects or user-uploaded content. In application and process logs, search for Node.js heap exhaustion, allocation failures, ENOMEM conditions, forced process exits, and restart events from process managers or orchestrators. In network telemetry, look for repeated large outbound downloads to allowed image hosts initiated by the application around the same time as /_next/image requests. Because exploitation may not leave a unique payload marker, detection should focus on the sequence of suspicious image optimizer requests followed by abnormal memory growth or availability failures.

• GET /_next/image
• POST /_next/image
• /_next/image?url=
• /_next/image?url=http%3A%2F%2F
• /_next/image?url=https%3A%2F%2F
• /_next/image?url=http://
• /_next/image?url=https://
• FATAL ERROR: Reached heap limit Allocation failed
• JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• CALL_AND_RETRY_LAST Allocation failed
• ENOMEM
• out of memory
• OOMKilled
• Killed process
• Container killed due to memory usage
• Exit Code 137
• signal: killed
• next-server
• node server.js

What your security team should do

• Inventory self-hosted Next.js applications and identify those using images.remotePatterns with external domains enabled.
• Prioritize upgrades for internet-facing applications, applications with broad wildcard remotePatterns, and applications whose allowed image domains accept user uploads.
• Upgrade to Next.js 15.5.10 or 16.1.5, or apply the upstream fixed commit 60a2aa97b6692d3a56e483f0ff93febaf6f33fd6 where applicable.
• Tighten images.remotePatterns to explicit trusted schemes, hosts, and paths; remove unnecessary wildcard domains.
• Add rate limits and request concurrency controls for /_next/image at CDN, reverse proxy, ingress, or WAF layers.
• Monitor for out-of-memory crashes, container restarts, spikes in /_next/image requests, and unusual outbound downloads from image domains.
• Review incident data since publication for signs of recurring memory exhaustion tied to image optimization requests.
• Document ownership and patch status for affected applications because this issue is configuration-dependent and may not be visible from package version alone.