Outdated Next.js Version Can Be Used to Slow Down or Crash Your Website

Vulnerability Explanation

The built-in image optimization pipeline in Next.js (the `/_next/image` endpoint) contains an uncontrolled recursion flaw (CWE-674). When image optimization is enabled with default settings, a remote attacker can send crafted requests to the image optimization endpoint that trigger excessive, uncontrolled recursion within the image processing logic. This causes the server's CPU to spike to near-100%, starving legitimate requests and producing a Denial of Service condition. The attack requires no authentication and has low complexity, but it is not automatable in a trivial way according to CISA's SSVC assessment.

Root Cause

The image optimization feature did not properly bound the amount of recursion that could occur during image processing. Without a recursion depth limit or adequate resource guard, a specially crafted request could cause the processor to recurse indefinitely, exhausting CPU resources (CWE-674: Uncontrolled Recursion).

Technical Impact

An unauthenticated remote attacker can cause excessive CPU consumption on the Next.js server, rendering the application slow or completely unresponsive. No data exfiltration or code execution is possible — impact is limited to availability.

Severity Justification

CVSS 5.9 (Medium) — network-accessible, no authentication required, low attack complexity, but impact is limited to availability only (no confidentiality or integrity impact). CISA rates exploitation as non-automatable with partial technical impact.

Affected Components

• next >= 10.0.0, < 14.2.7

Remediation Steps

1. Upgrade the `next` package to version 14.2.7 or later: `npm install next@latest` (or pin to `14.2.7` if you cannot move to the latest). This is the primary and recommended fix.
2. If an immediate upgrade is not feasible, apply the workaround in `next.config.js` by setting `images.unoptimized: true` or assigning a custom `images.loader` / `images.loaderFile`. This disables the vulnerable built-in optimizer.
3. After upgrading, run your test suite and verify the application starts correctly, as major version jumps (e.g., 12.x → 14.x) may require addressing breaking changes.
4. Deploy the updated build to production and confirm the running version via `npm list next` or by inspecting the `X-Powered-By` response header (if enabled).

Verification Steps

1. Run `npm list next` in the project root and confirm the version is 14.2.7 or higher.
2. Send a request to your image optimization endpoint (e.g., `curl -I 'https://yourdomain.com/_next/image?url=%2Fsome-image.jpg&w=800&q=75'`) and verify the server responds normally without CPU spikes.
3. Check your deployment pipeline or CI output to confirm the correct version of `next` was installed in the production build.

Code Examples (javascript)

// next.config.js — default config with no image settings (vulnerable)
module.exports = {
  // No images config — built-in optimizer is active
};

// Option A: Upgrade next to 14.2.7+ (preferred fix)
// package.json
{
  "dependencies": {
    "next": "^14.2.7"
  }
}

// Option B: Workaround — disable built-in image optimizer in next.config.js
module.exports = {
  images: {
    unoptimized: true,  // Disables the vulnerable built-in optimizer
  },
};

Best Practices

• Pin your `next` dependency to a specific minor version range (e.g., `^14.2.7`) and use a tool like Dependabot or Renovate to receive automated PRs for security patches.
• Restrict access to the `/_next/image` endpoint at the CDN or reverse-proxy layer with rate limiting to reduce the blast radius of any future DoS-class vulnerabilities.
• Run `npm audit` (or `pnpm audit`) as part of your CI pipeline to catch known vulnerabilities before they reach production.
• When upgrading across major Next.js versions, consult the official migration guide to avoid runtime regressions.

References

• github.com/vercel/next.js/security/advisories/GHSA-g77x-44xx-532m
• nvd.nist.gov/vuln/detail/CVE-2024-47831
• github.com/advisories/GHSA-g77x-44xx-532m