Next.js Pushes Emergency Fix for Two Critical Holes That Let Attackers Run Code

Key points

• Vercel shipped out-of-band patches for Next.js on October 14 covering two critical remote code execution bugs and one high-severity denial-of-service bug, with the SVG flaw inherited from the librsvg library used through the sharp image package.
• Both critical bugs are reachable over the network without any login, which is the worst-case rating for a web framework.
• Next.js is a React framework from Vercel used to build a large share of the sites and dashboards people use every day, so the blast radius is wide.
• Teams running self-hosted Next.js on their own servers carry the patching work themselves; Vercel-hosted apps get the fix pushed by the platform.

Vercel pushed an emergency security update for Next.js on October 14. It fixes two critical flaws that let an attacker run their own code on a vulnerable server without logging in, plus one high-severity bug that can knock a site offline.

If you run a site or an app on Next.js and haven't updated, a stranger on the internet can potentially make your server do what they want.

What actually broke?

Two separate problems, both reachable from outside. One sits in React Server Components, the part of Next.js that renders pages on the server before sending them to your browser. The other sits in how Next.js handles SVG images, the scalable graphics used for logos and icons.

The SVG bug lives inside librsvg, an open-source library for drawing SVG files that Next.js pulls in through a package called sharp. Next.js didn't write that code; it inherited the problem. That detail matters: a framework's attack surface includes every library underneath it, and image processing has been a soft underbelly of web stacks for years. This is the third Next.js remote code execution story we've covered since August, following our 27 August report on booby-trapped images and rigged URLs and our 23 September story on the ImageResponse SVG flaw.

Who is at risk?

Anyone self-hosting Next.js on their own infrastructure. If your team runs the framework on EC2, GKE or Azure App Service, the patching clock started on October 14. Vercel-hosted projects get the update from the platform, which is one of the reasons people pay for Vercel.

The failure mode here is familiar. A platform team pins a Next.js version in a Dockerfile a year ago, nobody owns the upgrade, and the SRE on call finds out there's a critical flaw when a scanner lights up on a Tuesday night.

What should site owners do?

Update Next.js to the fixed releases listed on the GitHub advisories, rebuild your container images, and redeploy. If you can't patch today, the stopgap for the image flaw is to stop accepting user-uploaded SVGs through the Next.js image pipeline until you can.

For ordinary readers: nothing to click, nothing to reset. The homework falls on the engineers who run the sites you visit. If a service has a quiet outage this week, this is a plausible reason.

Should you be more worried about one bug than the other?

Yes. The React Server Components flaw is the one that should scare platform teams more, because it sits in the core rendering path rather than an optional image feature. The SVG bug will get the headlines because librsvg is a known-messy dependency, but server components are on by default in modern Next.js apps.

First reported by The Hacker News, the out-of-band timing tells you Vercel didn't want this sitting in a normal release train. The pattern is getting repetitive: a serious middleware authorisation bypass earlier in the year, now two unauthenticated code-execution bugs together.

If you can't tell me which Next.js version is running in prod right now, you've got a bigger problem than this patch.