Nuxt patches eight security advisories at once, led by a critical DevTools RCE

Nuxt shipped 4.5.1, 3.21.10, and DevTools 3.3.1 on July 27 to close eight advisories, led by a critical DevTools remote code execution reachable from a malicious website you visit while the dev server runs, and a high-severity server-side RCE in server islands.

By Stackmaven

Nuxt, the Vue meta-framework that anchors a large share of production Vue apps, published a coordinated batch of eight security advisories on July 27 and shipped the fixes in Nuxt 4.5.1, Nuxt 3.21.10, and Nuxt DevTools 3.3.1. Two of them stand out: a critical remote code execution in DevTools that a malicious website can reach while your development server is running, and a high-severity server-side RCE in server islands. For any team running Nuxt in production or developing against it locally, this is a patch-now release rather than a read-later one.

What was disclosed

The advisories cluster around Nuxt’s newer server-rendering surfaces rather than its long-settled core. Alongside the two code-execution flaws, the batch includes a route rule authorization bypass, a server component denial-of-service, a cross-user disclosure of cached payloads, unauthorized component instantiation, and a development server path disclosure. Severities run from Critical down to Low, and the fixes land across all three packages at once.

The most operationally awkward detail is a regression note. One of the fixes repairs a flaw that was itself introduced by the earlier route-rule advisory (CVE-2026-53721). Teams that already patched for that issue are not covered: they still need this release. That is worth flagging because a partial upgrade here leaves a real hole rather than a cosmetic one.

The DevTools flaw is the one to treat as urgent

The critical entry, scored CVSS 9.6, is a remote code execution in Nuxt DevTools. Unauthenticated RPC methods were exposed over the Vite hot-module-reload websocket with no token or origin check, and chaining two of them lets a caller run an arbitrary command on the developer’s machine. The reachability is what makes it serious: the socket is reachable from another process on the same host, from a peer on the local network when the server runs with --host, and, most concerning, from a website you open in a browser tab while the dev server is live. That last vector turns a routine local development session into a drive-by code execution target.

DevTools runs only in development, so this is not a production exposure. But “development only” understates the risk when the trigger is visiting a web page. The practical read for a working developer is that an unpatched Nuxt project open on your laptop is enough, and no deploy is required for the flaw to matter. Nuxt DevTools 3.3.1 closes it.

The server-island RCE and the cached-payload leak

The high-severity production flaw is a server-side RCE via server island props, scored CVSS 8.1. It only fires when vue.runtimeCompiler is enabled, which is off by default, but where it is on, an attacker can inject a template key into island props and execute code inside the Nitro server process. The default-off configuration limits the blast radius, yet any app that opted into the runtime compiler should treat this as a direct server compromise path. It affects Nuxt 3.4.0 through 3.21.9 and 4.0.0 through 4.5.0.

The cross-user cached payload disclosure deserves its own line for teams that lean on caching. On Nuxt 4.4.0 and later, using the cache, swr, or isr route rules could serve one user’s _payload.json to another. Upgrading the framework is not sufficient on its own: a leaked payload may already sit in a CDN or edge cache, so you have to purge upstream caches after patching to be sure a pre-fix response is not still being served.

What to actually do

Upgrade to Nuxt 4.5.1 or Nuxt 3.21.10, and Nuxt DevTools to 3.3.1. The project’s npx nuxt upgrade --dedupe handles the version bump and deduplicates the lockfile, which matters here because several of the fixes live in transitive packages rather than the top-level nuxt dependency. If you serve cached route rules, purge your CDN or edge cache afterward. Nuxt 3 reaches end-of-life on July 31, so 3.21.10 is effectively a final security patch for that line: a Nuxt 3 app that skips it will be running unpatched within days, with no further fixes coming.

The wider signal

The pattern here echoes the six-advisory React Router batch from a week earlier. In both cases the flaws concentrate in the framework’s most recently added server-rendering machinery: server islands, cached payloads, and route rules for Nuxt, React Server Components handling for React Router. That is the recurring cost of fast-moving rendering models. New request paths and serialization boundaries arrive as fresh attack surface before the hardening catches up, and the meta-layer that stitches server and client together keeps being where the severity lands. The signal to watch is whether server islands, still a young feature, generate a second wave the way React Router’s RSC surface has. Stackmaven will check back on or around October 27.

Sources cited