Next.js Fixes 9 Vulnerabilities: Update to 16.2.11 or 15.5.21

Next.js published its July 2026 security update with fixes for nine vulnerabilities: four rated high severity and five rated medium severity. If you run a Next.js application on a VPS, dedicated server, or self-managed infrastructure, update to Next.js 16.2.11 or 15.5.21, depending on your current branch.

Summary: the issues include SSRF, Middleware/Proxy bypass, denial of service, cache confusion, and disclosure of internal Server Function identifiers. Patches have been available since July 20–21, 2026.

What Next.js fixed in July 2026

The official Next.js advisory recommends upgrading to 16.2.11, the Active LTS branch, or 15.5.21, the Maintenance LTS branch. Equivalent fixes were not announced for older minor branches: an application on Next.js 13, 14, or an earlier 15.x release needs to move to a supported patched version.

Self-managed deployments deserve particular attention because several conditions affect custom servers, dynamic rewrites, Server Actions, the Edge Runtime, Turbopack, or the built-in image optimizer.

The nine vulnerabilities and affected versions

Is active exploitation confirmed?

When the official advisories were reviewed on July 24, 2026, Vercel and GitHub did not report confirmed active exploitation of these nine CVEs, and none was found in the CISA KEV catalog. That does not prove private exploitation is absent: technical details and patches are now public, so administrators should update without waiting for attack telemetry.

How to update Next.js safely

1. Check the installed version

Run the following commands from the project directory:

npm ls next
node -p "require('next/package.json').version"

2. Back up the deployment and select the patched branch

Back up the code, environment variables, persistent files, and database. If you manage a virtual machine, take a snapshot before deployment. Then update to the patched release for your branch:

# 16.x branch
npm install [email protected]

# 15.5.x branch
npm install [email protected]

Use the equivalent command with pnpm or Yarn and preserve the lockfile. Do not install both versions; choose the branch that fits your compatibility plan.

3. Rebuild and test before restarting production

rm -rf .next
npm run build
npm test
npm ls next

Test routes protected by Middleware/Proxy, Server Actions, image loading and optimization, internationalization, caching, and any rewrite to external services. Deploy the resulting artifact and restart the process managed by systemd, PM2, Docker, or your orchestrator.

4. Verify the deployment

• Confirm that production reports version 16.2.11 or 15.5.21.
• Review 4xx/5xx errors, CPU and memory usage, latency, and process restarts.
• Verify that the lockfile and container image contain the patched version.
• Retain the snapshot only as long as needed and document the change.

Temporary mitigations when an immediate update is impossible

These mitigations reduce exposure but do not replace the patch:

• Rewrites and redirects: do not build external hostnames from user-controlled input. Restrict destinations to an allowlist.
• Custom server: pin and validate Host and X-Forwarded-Host at the reverse proxy. On compatible versions, set __NEXT_PRIVATE_ORIGIN to a trusted origin.
• Edge Runtime: limit request bodies to 5 MiB at the proxy or platform.
• Image optimization: block untrusted remote SVGs. The CVE-2026-64644 advisory also documents experimental.imgOptSkipMetadata: true as a temporary mitigation.
• Server Actions and cache: enforce authorization inside each use server or use cache boundary; do not treat an internal identifier as a secret.
• Availability: add rate limits, timeouts, and CPU/memory alerts at the proxy and Node.js process.

Recommendations for self-hosted Next.js on a VPS

Run the application under an unprivileged user, expose only the reverse proxy, restrict ports with a firewall, and keep secrets outside the repository. Automate dependency alerts, record the exact version in every release, and maintain a tested rollback path.

If you are planning to move a Node.js application to infrastructure with dedicated resources, snapshots, and operating-system control, review Teramont Host VPS plans. Application patching remains an administrator responsibility, but a clear operational foundation makes backups, monitoring, and recovery easier.

Frequently asked questions

Is Next.js 16.2.10 safe from these issues?

No. The patched release on the 16.x branch is 16.2.11. Check the lockfile and the version actually installed in production, not only package.json.

Can I remain on Next.js 15?

Yes, if you upgrade to 15.5.21, the Maintenance LTS release patched for this vulnerability set. Evaluate future support dates separately.

What if I use Next.js 13 or 14?

Plan a migration to 15.5.21 or 16.2.11. The July advisory does not provide a patched release within the 13 or 14 branches.

Does updating Node.js fix these CVEs?

No. The vulnerabilities are in the next package. Keeping Node.js current also matters, but you must update Next.js explicitly and rebuild the application.

Does a CDN or WAF remove the risk?

Not completely. It may reduce some attack paths through limits and validation, but it does not fix vulnerable server-side logic. Installing a patched release is the primary remediation.

Conclusion

Next.js 16.2.11 and 15.5.21 fix nine vulnerabilities with practical impact on self-managed applications. Inventory your deployments, prioritize those using Server Actions, custom servers, Turbopack, dynamic rewrites, or image optimization, and complete the upgrade with tests, monitoring, and a prepared rollback.

Official sources

• Next.js: July 2026 Security Release
• GitHub Advisory: CVE-2026-64645
• GitHub Advisory: CVE-2026-64649
• GitHub Advisory Database: recent advisories for the next package