CVE-2026-44577

What it actually does

CVE-2026-44577 is a denial-of-service vulnerability in self-hosted Next.js applications using the default image loader. In affected versions from 10.0.0 before 15.5.16 and 16.x before 16.2.5, the Image Optimization API endpoint, typically /_next/image, can fetch local image assets into memory without enforcing a maximum size limit. If an attacker can request a very large local asset that matches images.localPatterns, including the default permissive configuration, the server process may allocate excessive memory and terminate or become unresponsive due to an out-of-memory condition. The impact is availability loss only; the issue does not directly allow data disclosure, authentication bypass, or code execution.

Why it matters to the business

Successful exploitation can make a self-hosted Next.js application slow, unstable, or unavailable, affecting customer-facing web pages, APIs served by the same process, and dependent business workflows. Because the attack is unauthenticated and network-accessible, internet-facing applications are the highest priority, although the CVSS score is moderate, EPSS is currently low at 0.00722, and there is no known KEV listing or ransomware association. Organizations with many Next.js applications should still prioritize remediation because the vulnerable endpoint is common, the default configuration may be permissive, and repeated requests can create operational disruption, alert fatigue, autoscaling cost increases, and service-level agreement impact.

How an attack unfolds

An attacker first identifies a self-hosted Next.js application exposing the Image Optimization API. They then determine whether /_next/image is reachable and whether local image paths are allowed by the application’s images.localPatterns configuration. If a large local asset is accessible and matches the allowed pattern, the attacker sends crafted requests to /_next/image with URL parameters pointing to that asset and valid image optimization parameters such as width and quality. The vulnerable server attempts to read the local asset fully into memory before processing it. Repeating this request, or targeting especially large files, can exhaust memory in the Node.js process or container, causing crashes, restarts, degraded response times, or full application unavailability.

How to fix it

Upgrade affected self-hosted Next.js applications to a fixed release: 15.5.16 or later for the 15.x line, or 16.2.5 or later for the 16.x line. For older 10.x through 14.x deployments, migrate to a supported fixed Next.js version because the vulnerable range begins at 10.0.0. If immediate upgrade is not possible, reduce exposure by restricting images.localPatterns to only required trusted paths, avoid broad default-allow behavior, place a reverse proxy or WAF rule in front of /_next/image to enforce request rate limits and acceptable parameter patterns, limit maximum request and response body sizes where feasible, and configure process/container memory limits with health checks and safe restart behavior. Consider disabling or replacing the default image optimization path for applications that do not require it.

How to confirm the fix worked

Confirm the deployed Next.js version is 15.5.16 or later, or 16.2.5 or later, by checking package-lock.json, yarn.lock, pnpm-lock.yaml, npm list next, or the built application artifact. Review next.config.js or equivalent configuration to ensure images.localPatterns is explicitly scoped to required local paths and does not allow unnecessary broad matching. Verify that /_next/image remains functional for legitimate images after upgrade. Test that oversized or unexpected local image requests are rejected, limited, or handled without abnormal memory growth. Monitor application memory usage during controlled validation and confirm the server no longer loads unbounded local images into memory.

Typical attack path

1. Identify an internet-accessible self-hosted Next.js application.
2. Probe for the Image Optimization API at /_next/image.
3. Craft requests using the url parameter to reference large local image assets allowed by images.localPatterns.
4. Include otherwise valid image optimization parameters such as w and q to pass endpoint validation.
5. Send one or more large image optimization requests to force the server to load the asset into memory.
6. Repeat or parallelize requests until the Node.js process, container, or host experiences memory exhaustion.
7. Observe application errors, restarts, timeouts, or service unavailability.

How to detect it

To determine whether exploitation has already occurred, review web access logs, CDN logs, reverse proxy logs, application logs, container orchestration events, and host telemetry for abnormal /_next/image activity correlated with memory exhaustion. Look for bursts of requests to /_next/image using url parameters that point to unusually large local assets, repeated requests from the same source IPs or user agents, high response times, 499/500/502/503/504 errors, process restarts, Node.js heap out-of-memory messages, Linux OOM killer events, Kubernetes OOMKilled states, or container restarts. Pay special attention to timelines where /_next/image request spikes immediately precede application unavailability or memory alarms. Since no public exploit maturity or named threat actor activity is reported, detection should focus on behavioral indicators rather than known attacker infrastructure.

• GET /_next/image?url=
• POST /_next/image?url=
• /_next/image?url=
• /_next/image?url=%2F
• /_next/image?url=/
• w=
• q=
• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• Killed process
• Out of memory: Killed process
• OOMKilled
• Container killed due to memory usage
• next-server
• node

What your security team should do

• Inventory self-hosted Next.js applications, prioritizing internet-facing services using the default image loader.
• Upgrade affected deployments to Next.js 15.5.16 or later, or 16.2.5 or later, as appropriate.
• For unsupported 10.x through 14.x deployments, plan an expedited migration to a maintained fixed version.
• Review and tighten images.localPatterns so only necessary trusted local image paths are permitted.
• Add rate limiting and request filtering for /_next/image at the CDN, reverse proxy, ingress controller, or WAF layer.
• Monitor memory pressure, container OOM kills, process restarts, HTTP 5xx spikes, and unusual /_next/image request volume.
• Search historical logs for exploitation attempts involving repeated or unusually large /_next/image requests.
• Prepare operational runbooks for isolating abusive source IPs and temporarily disabling image optimization if active denial-of-service activity is observed.