Next.js Image Feature Can Be Abused to Fill Up Your Server's Disk

Vulnerability Explanation

The Next.js image optimization endpoint (`/_next/image`) writes a separate cached file to `.next/cache/images/` for every unique combination of source URL, width (`w`), and quality (`q`) query parameters. Prior to 16.1.7, the `ImageOptimizerCache` class had no upper bound on total cache size and no eviction policy. An unauthenticated remote attacker can enumerate the full matrix of allowed widths and quality values across any permitted image source, generating thousands of unique cache entries and exhausting server disk space, resulting in denial of service.

Root Cause

The `ImageOptimizerCache.set()` method in `next/dist/server/image-optimizer.js` wrote optimised images to disk without tracking cumulative cache size or evicting stale entries. No configurable limit existed, so cache growth was unbounded by design until 16.1.7 introduced an LRU eviction mechanism.

Technical Impact

Unauthenticated denial of service via disk exhaustion. An attacker can fill the server's available disk space, causing the application to crash or become unable to serve new requests. No data exfiltration or code execution is possible; impact is limited to availability.

Severity Justification

CVSS 4.0 score of 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L) per the official GitHub advisory. Network-accessible, no authentication required, low attack complexity, but impact is limited to availability (no confidentiality or integrity impact).

Affected Components

• next >= 10.0.0, < 16.1.7

Remediation Steps

1. Upgrade Next.js to 16.1.7 or later: `npm install next@latest` (or `yarn upgrade next`). This is the definitive fix.
2. After upgrading, optionally configure an explicit cache size cap in `next.config.js` using `images.maximumDiskCacheSize` (value in bytes). The new default is bounded by an LRU policy, but an explicit limit gives you predictable disk usage.
3. If you cannot upgrade immediately, add a cron job or scheduled task to periodically delete the contents of `.next/cache/images/` (e.g. daily via `find .next/cache/images -type f -mtime +1 -delete`).
4. Tighten image variant cardinality in `next.config.js`: restrict `images.deviceSizes`, `images.imageSizes`, `images.qualities`, `images.remotePatterns`, and `images.localPatterns` to only the values your application actually needs.
5. Add rate limiting on the `/_next/image` path at your reverse proxy or CDN layer to reduce the request rate an attacker can sustain.

Verification Steps

1. Run `npm list next` (or `yarn list next`) and confirm the installed version is 16.1.7 or higher.
2. Check `next.config.js` for the `images` block and confirm `maximumDiskCacheSize` is set or that you are on a version where the LRU default applies.
3. Monitor `.next/cache/images/` directory size over 24 hours after deployment to confirm it stays bounded.
4. Optionally, send a burst of requests to `/_next/image?url=<valid-image>&w=<varied>&q=<varied>` and verify the cache directory does not grow unboundedly.

Code Examples (javascript)

// next.config.js — Next.js 10.0.0–16.1.6
// No maximumDiskCacheSize option exists; cache grows without bound
module.exports = {
  images: {
    domains: ['example.com'],
    // No eviction, no size cap
  },
};

// next.config.js — Next.js 16.1.7+
// Upgrade first, then optionally set an explicit cap (bytes)
module.exports = {
  images: {
    remotePatterns: [
      { protocol: 'https', hostname: 'example.com' },
    ],
    // Optional: cap disk cache at 512 MB (default is now LRU-bounded)
    maximumDiskCacheSize: 512 * 1024 * 1024,
    // Restrict variants to reduce attack surface
    deviceSizes: [640, 750, 1080, 1920],
    imageSizes: [16, 32, 64, 128, 256],
    qualities: [75, 90],
  },
};

Best Practices

• Pin `images.remotePatterns` to only the hostnames and path prefixes your application genuinely needs — every additional allowed source increases the variant space.
• Set `images.qualities` explicitly to the smallest set of quality values your design requires; the default includes many values that expand the cache attack surface.
• Add disk-usage monitoring/alerting on your server so unbounded growth (from any cause) is caught early.
• Keep Next.js on a supported minor version and subscribe to the Vercel security advisory feed (GitHub Security Advisories for `vercel/next.js`).

References

• github.com/vercel/next.js/security/advisories/GHSA-3x4c-7xq6-9pq8
• github.com/vercel/next.js/releases/tag/v16.1.7
• github.com/vercel/next.js/commit/39eb8e0ac498b48855a0430fbf4c22276a73b4bd
• www.tenable.com/cve/CVE-2026-27980
• nvd.nist.gov/vuln/detail/CVE-2026-27980