CVE-2026-27980

What it actually does

Next.js versions 10.0.0 through versions prior to 16.1.7 can allow unauthenticated, network-reachable denial of service through the default image optimization endpoint, typically `/_next/image`. The disk cache used for optimized image variants has no configurable upper bound, so many unique combinations of image URL, width, quality, and related parameters can create unbounded files under `.next/cache/images`. An attacker does not need code execution or authentication; the impact is resource exhaustion, primarily disk-space consumption, which can lead to application errors, failed deployments, logging failures, container eviction, or service unavailability.

Why it matters to the business

Public-facing Next.js applications that use the built-in image optimizer can be made unavailable by filling local disk with cached image variants. The practical consequence is downtime or degraded service for websites, commerce flows, login portals, documentation sites, and other user-facing applications. Although this flaw is not known to be in CISA KEV and has low EPSS at this time, it is easy to trigger remotely when the image optimizer is exposed, so internet-facing deployments should treat it as an availability risk. The issue has broad ecosystem relevance because Next.js is widely used across modern web applications.

How an attack unfolds

An attacker first identifies a Next.js application exposing the image optimization route, commonly by requesting `/_next/image` or observing image URLs generated by the application. They then repeatedly request optimized images while varying request parameters such as `url`, `w`, and `q`, or by using many distinct source image URLs allowed by the application’s `images.localPatterns` or `images.remotePatterns` configuration. Each unique variant can be written to the image optimization disk cache. Because affected versions do not enforce an upper bound on that cache, sustained or distributed requests can cause `.next/cache/images` to grow until the filesystem is full. Once disk is exhausted, the application or hosting runtime may fail to write cache files, logs, temporary files, build artifacts, or runtime state, resulting in errors, degraded performance, container restarts, or full denial of service.

How to fix it

Upgrade Next.js to version 16.1.7 or later. Version 16.1.7 introduces an LRU-backed disk cache and the `images.maximumDiskCacheSize` setting, which evicts least-recently-used entries when the configured limit is exceeded. After upgrading, configure an appropriate `images.maximumDiskCacheSize` for the deployment’s available storage and traffic profile; setting `maximumDiskCacheSize: 0` disables disk caching. If immediate upgrade is not possible, reduce the ability to generate unique variants by tightening `images.localPatterns`, `images.remotePatterns`, and `images.qualities`, limiting accepted widths and qualities where feasible, applying rate limits to `/_next/image`, and periodically cleaning `.next/cache/images`. Also ensure application storage has monitoring and alerting for disk utilization and inode exhaustion.

How to confirm the fix worked

Confirm all deployed Next.js applications are running version 16.1.7 or later, or have equivalent mitigations in place. Review `package.json`, lockfiles, container images, build output, and runtime dependency inventories for `next` versions starting at 10.0.0 and below 16.1.7. Verify the application has a bounded image cache configuration using `images.maximumDiskCacheSize` where supported, or that disk caching is disabled with `maximumDiskCacheSize: 0` if appropriate. Validate that `images.localPatterns`, `images.remotePatterns`, and `images.qualities` are restrictive and do not permit unnecessary variant cardinality. In a controlled test environment, send repeated requests to `/_next/image` with varied allowed parameters and confirm cache size remains bounded and eviction occurs rather than unbounded growth. Monitor `.next/cache/images` size and disk utilization before and after testing.

Typical attack path

1. Find a public Next.js application that serves optimized images through `/_next/image`.
2. Confirm the image optimizer accepts requests with parameters such as `url`, `w`, and `q`.
3. Generate a large number of unique image optimization requests by varying source URLs, widths, qualities, or cache-busting query strings.
4. Sustain or distribute the request volume so each unique variant creates or attempts to create a new cache entry on disk.
5. Continue until `.next/cache/images` grows large enough to exhaust available disk space or trigger platform storage limits.
6. Cause application errors, failed writes, runtime instability, restarts, or service unavailability.

How to detect it

To determine whether exploitation already occurred, review web server, CDN, reverse proxy, application, and platform logs for unusual volume and high-cardinality requests to `/_next/image`. Focus on repeated requests from one or many IP addresses where query parameters vary heavily, especially `url=`, `w=`, and `q=`. Look for sudden growth in `.next/cache/images`, disk-full errors, failed writes, application restarts, container evictions, deployment failures, or 5xx spikes correlated with image optimization traffic. Useful log sources include CDN access logs, load balancer logs, NGINX/Apache logs, platform runtime logs, container orchestrator events, Next.js application logs, host disk metrics, and filesystem telemetry. Search for errors such as `ENOSPC`, `no space left on device`, failed cache writes, and image optimizer exceptions near the time of abnormal `/_next/image` activity. There are no public named threat actors or ransomware campaigns associated with this vulnerability in the provided data, so detection should emphasize behavioral indicators rather than actor-specific infrastructure.

• GET /_next/image
• /_next/image?url=
• /_next/image?
• url=
• &w=
• &q=
• .next/cache/images
• ENOSPC
• no space left on device
• No space left on device
• disk full
• write ENOSPC
• cache/images

What your security team should do

• Inventory internet-facing Next.js applications and prioritize those using the built-in image optimizer route `/_next/image`.
• Upgrade affected applications to Next.js 16.1.7 or later during the next urgent patch window, prioritizing public high-traffic services and environments with limited ephemeral storage.
• Configure `images.maximumDiskCacheSize` after upgrade, or set it to `0` to disable disk caching where operationally acceptable.
• Until upgraded, apply compensating controls: rate-limit `/_next/image`, restrict allowed remote and local image sources, reduce allowed image qualities and widths, and schedule cleanup of `.next/cache/images`.
• Add monitoring and alerts for rapid growth of `.next/cache/images`, high disk utilization, inode exhaustion, and elevated `/_next/image` request volume.
• Review access logs for abnormal spikes in unique `/_next/image` requests, especially high-cardinality combinations of `url`, `w`, and `q` parameters.
• Prepare operational runbooks for emergency cache cleanup and temporary image optimizer restriction if disk usage spikes.