Next.js Image Feature Can Be Abused to Take Your Website Offline

Vulnerability Explanation

The Next.js built-in Image Optimisation endpoint (`/_next/image`) fetches remote images and processes them in memory before serving an optimised version to the client. In affected versions, there is no enforced maximum size limit on the remote image fetched. An attacker who can host or control a sufficiently large image on any domain permitted by the application's `remotePatterns` configuration can trigger repeated optimisation requests, causing the Node.js process to exhaust available memory and crash. The attack is network-accessible and requires no authentication — only the ability to serve a large file from an allowed hostname.

Root Cause

The image optimisation pipeline loads the full remote image payload into memory before processing, with no upper bound on the response body size. This is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). The missing guard means that resource consumption is entirely controlled by the content of the remote server, not by the application itself.

Technical Impact

An unauthenticated attacker can cause the Node.js server process to terminate due to out-of-memory conditions, resulting in a full denial of service. Recovery requires a process restart. Repeated requests can sustain the outage. There is no data exfiltration or code execution risk — the impact is limited to availability.

Severity Justification

CVSS 5.9 (Moderate) per the official GitHub Security Advisory (GHSA-9g9p-9gw9-jx7f). Network-accessible with no authentication required, but exploitation is conditional: the attacker must be able to serve a large image from a domain already trusted in remotePatterns, limiting the realistic attacker pool.

Affected Components

• next >= 10.0.0, < 15.5.10
• next >= 15.6.0-canary.0, < 16.1.5

Remediation Steps

1. Upgrade Next.js to 15.5.10 (stable) or 16.1.5 (canary track): `npm install next@15.5.10` or `npm install next@16.1.5`. This is the primary and recommended fix.
2. If an immediate upgrade is blocked, tighten `remotePatterns` in `next.config.js` to the narrowest possible scope — use exact hostnames and specific `pathname` prefixes rather than wildcards. Avoid patterns like `hostname: '**.example.com'` unless strictly necessary.
3. If you cannot upgrade and need a short-term workaround, consider routing image optimisation through an external CDN (e.g. Cloudflare Images, Imgix, Cloudinary) using a custom `loaderFile`. This offloads the memory-intensive processing away from your Node.js server.
4. After upgrading, verify the installed version and redeploy. Confirm the `/_next/image` endpoint is served by the patched build.

Verification Steps

1. Run `npm list next` or `cat node_modules/next/package.json | grep '"version"'` to confirm the installed version is 15.5.10 or later.
2. Make a test request to `/_next/image?url=<allowed-url>&w=800&q=75` and confirm it returns a valid optimised image without errors.
3. Review `next.config.js` to confirm `remotePatterns` entries use specific hostnames and pathnames rather than broad wildcards.

Code Examples (javascript)

// next.config.js — vulnerable: broad wildcard remotePatterns, Next.js < 15.5.10
module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: '**.example.com', // overly broad
      },
    ],
  },
};

// next.config.js — fixed: upgrade Next.js AND narrow remotePatterns
// 1. Upgrade: npm install next@15.5.10
// 2. Tighten remotePatterns to specific paths
module.exports = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'assets.example.com',  // exact hostname
        pathname: '/uploads/**',          // specific path prefix
      },
    ],
  },
};

Best Practices

• Pin `remotePatterns` to the narrowest hostname and pathname scope your application actually needs — avoid wildcards unless required.
• Set up automated dependency update tooling (e.g. Dependabot or Renovate) to receive Next.js security patches promptly.
• Place a reverse proxy (e.g. Nginx, Cloudflare) in front of your Node.js server with request rate limiting on `/_next/image` to reduce the blast radius of resource-exhaustion attacks.
• Consider offloading image optimisation to a dedicated external service (Cloudflare Images, Imgix, Cloudinary) for production workloads — this removes the attack surface from your application server entirely.

References

• github.com/vercel/next.js/security/advisories/GHSA-9g9p-9gw9-jx7f
• nvd.nist.gov/vuln/detail/CVE-2025-59471
• vercel.com/changelog/summaries-of-cve-2025-59471-and-cve-2025-59472
• github.com/vercel/next.js/releases/tag/v15.5.10
• github.com/vercel/next.js/releases/tag/v16.1.5