CVE-2026-27980: Vercel Next.js DOS Vulnerability

CVE-2026-27980 Overview

Next.js, the popular React framework for building full-stack web applications, contains a resource exhaustion vulnerability in its image optimization disk cache functionality. Starting in version 10.0.0 and prior to version 16.1.7, the default Next.js image optimization disk cache (/_next/image) did not have a configurable upper bound, allowing unbounded cache growth. An attacker could generate many unique image-optimization variants and exhaust disk space, causing denial of service.

Critical Impact

Attackers can exhaust server disk space by generating numerous unique image optimization variants, leading to denial of service conditions that affect application availability.

Affected Products

• Vercel Next.js versions 10.0.0 through 16.1.6

Discovery Timeline

• 2026-03-18 - CVE CVE-2026-27980 published to NVD
• 2026-03-18 - Last updated in NVD database

Technical Details for CVE-2026-27980

Vulnerability Analysis

This vulnerability represents a classic CWE-400 (Uncontrolled Resource Consumption) flaw in the Next.js image optimization subsystem. The image optimization feature at the /_next/image endpoint processes and caches optimized versions of images based on requested parameters such as width, quality, and format. Prior to the fix, this cache implementation lacked any mechanism to limit its growth or evict old entries.

The architectural oversight means that each unique combination of image source, dimensions, and quality settings creates a new cache entry on disk. Since the cache had no maximum size configuration or eviction policy, attackers could systematically request images with varying parameters to continuously expand the cache directory until the server's disk space is exhausted.

Root Cause

The vulnerability stems from the absence of an upper bound configuration for the image optimization disk cache. The .next/cache/images directory could grow indefinitely without any Least Recently Used (LRU) eviction mechanism or size limits. The framework trusted that cache entries would be naturally bounded by legitimate usage patterns, but this assumption fails under adversarial conditions where an attacker deliberately generates high-cardinality cache entries.

Attack Vector

An attacker can exploit this vulnerability remotely over the network without authentication. The attack requires sending HTTP requests to the /_next/image endpoint with systematically varied query parameters (width, quality, source URL) to generate unique cached variants. By automating these requests with incremental or randomized parameter values, an attacker can rapidly fill disk space. The attack is low complexity as it only requires basic HTTP request capabilities and knowledge of the Next.js image optimization URL pattern.

The security patch introduces LRU-backed disk caching with the new images.maximumDiskCacheSize configuration option:

           .optional(),
         loader: z.enum(VALID_LOADERS).optional(),
         loaderFile: z.string().optional(),
+        maximumDiskCacheSize: z.number().int().min(0).optional(),
         maximumRedirects: z.number().int().min(0).max(20).optional(),
         maximumResponseBody: z
           .number()

Source: GitHub Commit

Additional error handling was added to support the LRU cache tracking:

   "1065": "createServerPathnameForMetadata should not be called in client contexts.",
   "1066": "createServerSearchParamsForServerPage should not be called in a client validation.",
   "1067": "The Next.js unhandled rejection filter is being installed more than once. This is a bug in Next.js.",
-  "1068": "Expected workStore to be initialized"
+  "1068": "Expected workStore to be initialized",
+  "1069": "Invariant: cache entry \"%s\" not found in dir \"%s\"",
+  "1070": "image of size %s could not be tracked by lru cache"
 }

Source: GitHub Commit

Detection Methods for CVE-2026-27980

Indicators of Compromise

• Unusually rapid growth of the .next/cache/images directory
• High volume of requests to /_next/image endpoint with varying query parameters
• Disk space utilization alerts triggered on application servers
• Error logs indicating disk write failures or "no space left on device" messages

Detection Strategies

• Monitor HTTP access logs for patterns of sequential or randomized requests to the /_next/image endpoint from single sources
• Implement rate limiting on the image optimization endpoint to detect and block high-frequency requests
• Set up file system monitoring to alert on unexpected growth rates in the .next/cache/images directory
• Use web application firewall (WAF) rules to detect and flag suspicious image optimization request patterns

Monitoring Recommendations

• Configure disk space utilization alerts with appropriate thresholds for production servers
• Implement application-level logging for image optimization cache operations
• Deploy endpoint monitoring to track request volumes and parameter diversity on /_next/image
• Establish baseline metrics for normal cache directory growth to enable anomaly detection

How to Mitigate CVE-2026-27980

Immediate Actions Required

• Upgrade to Next.js version 16.1.7 or later to receive the security fix
• If upgrade is not immediately possible, implement periodic cleanup of the .next/cache/images directory
• Reduce variant cardinality by tightening images.localPatterns, images.remotePatterns, and images.qualities configuration values
• Implement rate limiting on the /_next/image endpoint at the web server or CDN level

Patch Information

Vercel has released version 16.1.7 of Next.js which addresses this vulnerability by adding an LRU-backed disk cache with the images.maximumDiskCacheSize configuration option. The fix includes automatic eviction of least-recently-used entries when the configured limit is exceeded. For detailed patch information, see the GitHub Security Advisory GHSA-3x4c-7xq6-9pq8 and the GitHub Release v16.1.7.

Workarounds

• Set maximumDiskCacheSize: 0 in your Next.js configuration to completely disable disk caching
• Implement a cron job or scheduled task to periodically purge the .next/cache/images directory
• Restrict allowed image dimensions and quality settings to reduce cache variant cardinality
• Deploy behind a CDN with aggressive caching to reduce direct hits to the origin server's image optimization endpoint

# Configuration example
# next.config.js - Configure disk cache limit
module.exports = {
  images: {
    maximumDiskCacheSize: 52428800, // 50MB limit
    // Or disable disk caching entirely:
    // maximumDiskCacheSize: 0,
  },
}

# Cron job to clean cache directory (workaround for unpatched versions)
# Add to crontab: 0 */4 * * * /path/to/clean-cache.sh
#!/bin/bash
find /app/.next/cache/images -type f -mtime +1 -delete