CVE-2026-64644

What it actually does

CVE-2026-64644 is a denial-of-service weakness in self-hosted Next.js applications using the default image loader with config.images.remotePatterns configured. In affected Next.js versions 15.5.0 through 15.5.20 and 16.0.0 through 16.2.10, the Image Optimization API can be forced to process malicious remotely hosted images that match allowed remotePatterns. Processing those images can consume excessive CPU in the /_next/image endpoint, reducing application availability. The issue does not affect Vercel-hosted deployments, applications using config.images.unoptimized: true, applications using config.images.loader: 'custom', or configurations that do not allow remote image optimization through remotePatterns.

Why it matters to the business

Successful exploitation can make affected web applications slow or unavailable by exhausting server CPU, potentially causing customer-facing outages, failed transactions, degraded user experience, elevated infrastructure costs from autoscaling, and increased operational burden for incident response. The current EPSS score is low, it is not listed in CISA KEV, and no mature exploit is reported, but internet-facing self-hosted Next.js services with permissive remote image patterns should treat this as a near-term availability risk because exploitation requires no authentication once the vulnerable configuration is present.

How an attack unfolds

An attacker first identifies a self-hosted Next.js application exposing the /_next/image optimization endpoint and determines that it is running an affected Next.js release with remote image optimization enabled through images.remotePatterns. The attacker then hosts or locates a specially crafted remote image whose URL matches one of the configured remotePatterns. By sending requests to /_next/image with the malicious remote image URL and valid image optimization parameters, the application retrieves and attempts to optimize the image. The vulnerable image processing path consumes excessive CPU. Repeated requests, or concurrent requests from multiple clients, can keep application workers busy and degrade or deny service to legitimate users. Exploitation is limited to deployments where the required image configuration is present; the vulnerable behavior is not enabled by default for all Next.js applications.

How to fix it

Upgrade Next.js to a fixed version: 15.5.21 or later for the 15.5.x line, or 16.2.11 or later for the 16.x line. If immediate upgrade is not possible, reduce exposure by disabling remote image optimization where feasible, setting images.unoptimized: true, using a custom image loader, or tightly restricting images.remotePatterns to trusted hosts only. Remove broad wildcard remotePatterns and avoid allowing attacker-controllable image origins. Apply rate limiting, request concurrency limits, CDN/WAF throttling, and caching controls for /_next/image to reduce denial-of-service impact. Vercel-hosted deployments and applications configured with a custom loader or unoptimized images are not affected by this specific issue, but package versions and configuration should still be reviewed.

How to confirm the fix worked

Confirm the installed Next.js version is no longer in the affected ranges 15.5.0-15.5.20 or 16.0.0-16.2.10 by checking package manifests, lockfiles, container images, and deployed build artifacts. Review next.config.js or equivalent configuration for images.remotePatterns, images.unoptimized, and images.loader. A remediated deployment should either run Next.js 15.5.21 or 16.2.11 or later, or avoid the affected default remote image optimization path. Validate that /_next/image remains functional for legitimate images after upgrade and that broad or unnecessary remotePatterns have been removed. Use controlled, benign load testing against /_next/image to confirm CPU usage remains stable and rate limits behave as expected; do not test with untrusted malicious image samples in production.

Typical attack path

1. Find internet-facing Next.js applications and probe for the /_next/image endpoint.
2. Identify deployments likely to be self-hosted and using affected Next.js versions 15.5.0-15.5.20 or 16.0.0-16.2.10.
3. Determine whether remote image optimization is allowed by submitting image URLs that match permitted remotePatterns.
4. Host or reference a malicious remote image that matches an allowed remote pattern.
5. Send repeated GET requests to /_next/image with the malicious remote image URL and valid width/quality parameters.
6. Force the server-side image optimizer to consume excessive CPU.
7. Sustain request volume until the application slows, returns errors, autoscaling increases, or the service becomes unavailable.

How to detect it

To determine whether this was already exploited, review web server, CDN, WAF, reverse proxy, and application logs for abnormal volumes of requests to /_next/image, especially requests containing remote URL parameters. Correlate request spikes with elevated Node.js CPU usage, increased event-loop delay, high response latency, 499/500/502/503/504 responses, container restarts, autoscaling events, or health-check failures. Look for repeated requests to the same remote image URL, many unique remote image URLs from the same source, unusual width or quality parameter combinations, and remote image origins that are not expected for the application. Review APM traces and runtime metrics for expensive image optimization calls, long-running requests, and CPU saturation in Node.js or Next.js server processes. If available, inspect outbound network logs for bursts of server-side fetches to unfamiliar remote image hosts that correspond to inbound /_next/image requests. Because this flaw causes resource exhaustion rather than code execution, durable host artifacts may be limited; detection should focus on traffic patterns, performance telemetry, and source IP or URL repetition around outage windows.

• GET /_next/image?url=
• /_next/image?url=
• /_next/image
• images.remotePatterns
• remotePatterns
• next.config.js
• next-server
• node

What your security team should do

• Inventory self-hosted Next.js applications and prioritize those exposed to the internet.
• Identify applications running Next.js 15.5.0-15.5.20 or 16.0.0-16.2.10.
• Review image configuration for images.remotePatterns; prioritize deployments with broad wildcards or user-controllable remote image sources.
• Upgrade affected applications to Next.js 15.5.21, 16.2.11, or later.
• Add CDN, WAF, or reverse-proxy rate limits for /_next/image, especially for repeated requests with remote URL parameters.
• Monitor CPU, request latency, 5xx responses, and request volume for /_next/image endpoints.
• Restrict remote image sources to trusted domains and remove unnecessary patterns.
• Create detection rules for spikes in /_next/image traffic containing remote URL parameters.
• Ensure incident runbooks include temporary mitigations such as disabling remote image optimization, tightening remotePatterns, or blocking abusive sources.