Skip to content

chore(deps): update devdependency nuxt to v4.5.1 [security] - #999

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-nuxt-vulnerability
Open

chore(deps): update devdependency nuxt to v4.5.1 [security]#999
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-nuxt-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
nuxt (source) 4.4.7 → 4.5.1 age confidence

Nuxt: Unauthenticated out-of-memory crash via unbounded v-for expansion in island rendering

CVE-2026-71314 / GHSA-hxcr-hm88-mpq6

More information

Details

Impact

An unauthenticated attacker can crash a Nuxt server that renders any island / server component containing a v-for over a prop (for example v-for="n in count" or a <slot v-for>). Because the island URL hash is a non-secret digest of the request, the attacker can compute a valid hash for arbitrary props and send the iterated prop as a large integer. The server then expands the v-for to that many nodes during SSR, allocating memory proportional to the attacker's number. Reporter figures: count=8000000 produced a 142.9 MB response; count=40000000 (and items=4000000 on a slot list) produced an out-of-memory crash of the worker from a single ~130-byte request. Both the plain v-for path (Vue's ssrRenderList) and the slot path (vforToArray) are affected.

Patches

Fixed in nuxt@4.5.1 and nuxt@3.21.10. Island/server-component v-for sources are now clamped to a maximum iteration count (MAX_VFOR_LENGTH = 100000) at the render boundary, covering the plain path, the <slot v-for> element, and the vforToArray slot-props helper. Combined with the body-size cap (GHSA-9pgf-384g-p7mv), a single island render can no longer allocate without bound regardless of which v-for path is used or whether the prop arrives as an integer or an array.

Workarounds

Avoid v-for directly over an unclamped prop in server components, or clamp the count in the component (v-for="n in Math.min(count, 1000)"). A body-size limit in front of /__nuxt_island/ only mitigates array-shaped inputs, not the integer-amplification case.

References
  • Bound helper: packages/nuxt/src/app/components/vfor.ts
  • Transform: packages/nuxt/src/components/plugins/islands-transform.ts
  • Slot helper: packages/nuxt/src/app/components/utils.ts (vforToArray)

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Nuxt route rules silently dropped for mixed-case paths, bypassing appMiddleware auth gates (incomplete fix for CVE-2026-53721)

CVE-2026-71315 / GHSA-hxvh-4h3w-prp9

More information

Details

Impact

Nuxt matches route rules case-insensitively by default (mirroring vue-router's default sensitive: false routing). The fix for GHSA-mm7m-92g8-7m47 / CVE-2026-53721 lowercased the lookup path before matching route rules, but the route-rule keys compiled into the matcher were left verbatim. As a result, any route rule whose key contains an uppercase character (for example /Admin, /Dashboard/**, or the rules Nuxt derives from PascalCase/camelCase page files such as pages/Admin.vue) never matches, because every lookup is folded to lowercase while the key stays mixed-case.

vue-router still serves the page case-insensitively, so the page renders with none of its Nuxt route-rule protections applied. The most serious consequence is an authorization bypass: an appMiddleware rule used as an auth gate (routeRules: { '/Admin/dashboard': { appMiddleware: 'auth' } }) is dropped, and /Admin/dashboard, /admin/dashboard, and /ADMIN/dashboard all render the protected page (and its SSR-fetched data) to an unauthenticated visitor instead of redirecting to login. The same gap drops Nuxt's other app-side route-rule behaviours for mixed-case keys, including the client redirect middleware, the app-side ssr: false decision, prerender, and payload handling.

Patches

Fixed in nuxt@4.5.1 (4.x) and nuxt@3.21.10 (3.x). The route-rule matcher now case-folds the compiled keys the same way it folds the lookup path, so key and lookup normalisation are symmetric. Both sides are gated on router.options.sensitive: with sensitive: true (case-sensitive routing) configured casing is preserved on both sides.

Scope note: server-emitted per-route headers, server redirect, and proxy are matched by Nitro's own case-sensitive route-rule matcher, not by Nuxt's app-level matcher. They are unchanged by this advisory. The fix covers the app-level protections Nuxt owns (appMiddleware, appLayout, the client redirect middleware, the app ssr decision, prerender, and payload).

Workarounds

If you cannot upgrade immediately, any one of:

  • Key all routeRules (and name your page files) in lowercase, so the keys already match the folded lookup path.
  • Set router: { options: { sensitive: true } } so routing and route-rule matching are both case-sensitive and exact (requests must then use the exact casing).
  • Enforce the sensitive protections server-side independently of route rules (for example a server middleware that checks auth), which does not rely on case-insensitive route-rule matching.

Severity

  • CVSS Score: 8.2 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Nuxt runtime payload cache discloses another user's SSR data across users and to unauthenticated clients

CVE-2026-71316 / GHSA-wm8w-6qjm-cv43

More information

Details

Impact

When a page is covered by routeRules cache / swr / isr, Nuxt enables runtime payload extraction and serves /<page>/_payload.json. On affected versions the renderer stored the SSR payload in the shared cache:nuxt:payload storage under a path-only key (no cookie, authorization, or cache.varies dimension) and, on a later payload request, returned the cached entry before route middleware / page guards ran again.

As a result, once any authenticated user warms a protected, cached page, a subsequent GET /<page>/_payload.json from an unauthenticated client or a different authenticated user receives the first user's payload: the full SSR data for that route, including anything loaded via useFetch / useAsyncData (for example /api/me: profile, tenant, billing, token-like values). The HTML response stays correctly varied and protected; only the extracted payload leaks. Both cross-user (A warms, B receives A) and unauthenticated disclosure are exploitable. cache.varies does not mitigate it, because the payload cache ignores varies.

Introduced when runtime payload extraction landed for cached routes (#​34410); the regression is specific to the 4.x line, where the runtime cache:nuxt:payload storage was added and the import.meta.prerender gate on the payload-cache read/writes was dropped. The 3.x line shipped the same feature with the gate intact and is not affected.

Patches

Fixed in nuxt@4.5.1. Runtime payload-cache reads and writes are again confined to prerendering (import.meta.prerender); at runtime, /<page>/_payload.json follows the normal render path so route middleware, routeRules.appMiddleware, and page guards run for the current request. main / v5 and the 3.x line already had this property, so 3.x is not affected.

Workarounds
  • Set experimental.payloadExtraction: false (reporter-validated): the standalone /_payload.json endpoint returns 404 and the page still serves a 200 with an inline payload.
  • Do not apply cache / swr / isr to authenticated pages that render user-specific SSR data.
  • As defense-in-depth, require authentication for /**/_payload.json at a proxy / CDN.
  • After upgrading, purge any CDN / platform cache that may already hold protected payloads.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Nuxt: Unauthorized Component Instantiation via Server Island Props

CVE-2026-71318 / GHSA-48hr-524c-v5w3

More information

Details

Impact

Nuxt server islands accept props via the /__nuxt_island/ endpoint. When an application has a server island component that forwards props directly into Vue's dynamic component resolution (<component :is>, resolveDynamicComponent, or h()), an attacker can pass a plain string value (rather than a component definition) to instantiate any globally-registered Vue component or any native HTML element.

For example:

{ "as": "SomeGlobalComponent" }

...resolves and renders SomeGlobalComponent if it is globally registered, even though the attacker should only be able to drive props for the island's declared component. Similarly, { "as": "iframe" } renders an <iframe> element.

Unlike the primary RCE vector (GHSA-9473-5f9j-94wq), this does not require vue.runtimeCompiler to be enabled. A plain string prop is sufficient to trigger component resolution. The template/render key guard that addresses the RCE vector does not block plain string values.

Some component libraries expose a polymorphic as / asChild prop that forwards its value into <component :is>; @nuxt/ui (via reka-ui) is a widely used example. An application is affected if such a component receives the attacker-controlled value inside a server island. Note this does not require explicit prop forwarding: island props the island component does not declare fall through as attributes onto its single root element, so an island whose root is a reka-ui / @nuxt/ui component receives the attacker's as value implicitly. Unlike the RCE vector, no vue.runtimeCompiler is required, which makes this vector reachable in more configurations. These libraries are not themselves vulnerable; they are noted only because they commonly provide the dynamic-component sink. Installing @nuxt/ui does not by itself register any component as a server island: the application must define the island (a .server.vue file).

Mitigating factors
  • Exploitation requires a server island component that puts an attacker-controlled value onto a dynamic-component path (<component :is>, resolveDynamicComponent, h(), or a polymorphic as / asChild prop), either explicitly or via attribute fallthrough when the island's root is such a component.
  • Reachable components are limited to what is actually in the island app's global registry. In a default pages-enabled app that is RouterView and RouterLink (both registered globally by the pages router plugin, which runs even in component islands), plus any components/global/ component and any component a module registers globally. RouterLink in particular renders an attacker-influenced <a> (and, because an island that declares no props forwards all props, to and other RouterLink props ride the same fallthrough). Vue built-ins (Transition, KeepAlive, Teleport, Suspense) and Nuxt auto-imports (ClientOnly, NuxtLink, NuxtPage, etc.) are NOT in the island app's global registry and cannot be resolved this way; an unresolved name instead renders as a native HTML element (the element-injection half of this issue).
  • Declaring the props an island accepts, or setting inheritAttrs: false on it, prevents an undeclared as from falling through to a polymorphic root and neutralizes this vector.
  • Arbitrary JavaScript execution is not possible through this vector (no template/render compilation).
  • Island component names are constrained to the build-time component registry; an attacker cannot resolve arbitrary components.
Affected versions

Nuxt >=3.1.0 <3.21.10 and >=4.0.0 <4.5.1, with component islands active. The island prop-forwarding behavior has existed since server islands were introduced in v3.1.0, and this vector does not depend on vue.runtimeCompiler. Nuxt 2 is not affected.

Note the patch (below) closes the implicit attribute-fallthrough path, which is the majority case. An island that explicitly forwards an untrusted prop into dynamic component resolution (or forwards it under a prop name other than as) remains the application's responsibility in every version; see Workarounds.

Patches

Fixed in nuxt@4.5.1 and nuxt@3.21.10. Patched releases reject a top-level as island prop (HTTP 400 at the /__nuxt_island/ endpoint). This closes the implicit path: island props an island does not declare fall through as attributes onto its single root, so a top-level as would otherwise reach a polymorphic root component's as prop (the reka-ui / @nuxt/ui convention) and drive dynamic component resolution without the author binding it. Rejecting the top-level as prop blocks that fallthrough while leaving nested data and other prop names untouched.

The framework deliberately does not attempt to block every case: it cannot safely tell a string used as data from one used as a component selector, and it has no island-local hook into Vue's h() or resolveDynamicComponent(). An island that explicitly forwards an untrusted value into <component :is> / h() / resolveDynamicComponent(), or that forwards it under a different polymorphic prop name, is therefore not covered by the patch and must follow the guidance below. The Nuxt documentation now warns against this.

Workarounds

Upgrade to nuxt@4.5.1 or nuxt@3.21.10. That upgrade also removes the related object-prop RCE (GHSA-9473-5f9j-94wq). In addition, in any version:

  1. Do not forward island props into <component :is>, resolveDynamicComponent, or h(). Map an untrusted discriminator through a closed allowlist of imported component definitions instead of passing the raw prop value.
  2. Declare the props an island accepts, or set inheritAttrs: false on it, so request input cannot fall through to a polymorphic root component.
  3. Avoid registering sensitive components globally that could leak information if instantiated by an attacker.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Nuxt: Server-Side Remote Code Execution via Runtime Template Injection in Nuxt Server Island Props

CVE-2026-71320 / GHSA-9473-5f9j-94wq

More information

Details

Impact

Nuxt server islands accept props via the /__nuxt_island/ endpoint. When vue.runtimeCompiler: true is enabled (off by default) and the application has a server island component that forwards props into Vue's dynamic component resolution (<component :is>, resolveDynamicComponent, or h()), an attacker can inject a template key into the island props to achieve server-side remote code execution in the Nitro process.

{ "as": { "template": "<attacker-controlled>" } }

Vue's runtime template compiler compiles and executes the attacker-controlled template in the server process. The same primitive also works on the client side when the runtime compiler is active there, though the server-side path is the primary concern.

Some component libraries expose a polymorphic as / asChild prop that forwards its value into <component :is>; @nuxt/ui (via reka-ui) is a widely used example. An application is affected if such a component receives the attacker-controlled value, provided vue.runtimeCompiler is also enabled. Note this does not require the island author to explicitly forward a prop: island props that the island component does not declare fall through as attributes onto its single root element (standard Vue attribute inheritance), so an island whose root is a polymorphic component receives the attacker's as value implicitly. These libraries are not themselves vulnerable; they are noted only because they commonly provide the dynamic-component sink.

Common configurations that satisfy the preconditions

The flaw is in Nuxt core. The library below is not itself vulnerable; it is noted because it commonly provides the dynamic-component sink an application might inadvertently expose.

  • @nuxt/ui (via its underlying reka-ui primitives) exposes a polymorphic as / asChild prop that is forwarded into Vue's dynamic-component resolution. Installing @nuxt/ui does not by itself register any component as a server island. Exploitation requires the application to define an island component (a .server.vue file) whose rendered output puts the attacker-controlled value on such a component's as / asChild prop; with vue.runtimeCompiler: true, the attacker-controlled template is then compiled and executed. Because undeclared island props fall through as attributes to the single root, this can happen without any explicit binding: an island whose root is a reka-ui / @nuxt/ui component is enough. An example vulnerable island (the as value falls through to UButton, no explicit forwarding needed):

    <!-- components/MyWidget.server.vue -->
<template>
  <UButton>Save</UButton>
</template>

The island URL hash (/__nuxt_island/<Name>_<hash>.json) is a deterministic (unsalted) content hash, not an authentication token. It provides integrity relative to the URL but is not a security boundary: an attacker who knows the component name and desired props can compute a valid hash.

Mitigating factors
  • vue.runtimeCompiler is off by default in Nuxt. The vast majority of Nuxt applications are not affected.
  • Exploitation requires a second precondition: the application must have a server island component that puts an attacker-controlled value onto a dynamic-component path (<component :is>, resolveDynamicComponent, h(), or a polymorphic as / asChild prop). This can occur explicitly or via attribute fallthrough when the island's root is such a component.
  • SSG / static deployments are largely unreachable via this vector (no server process to exploit).
  • Island component names are constrained to the build-time component registry; an attacker cannot resolve arbitrary components.
Affected versions

Nuxt >=3.4.0 <3.21.10 and >=4.0.0 <4.5.1, and only when vue.runtimeCompiler: true and component islands are active. Earlier versions did not allow the Vue compiler to be enabled in the server bundle (the compiler dependencies have been mock-aliased on the server since v3.0.0-rc.1), so the runtime-compilation path is not reachable. Nuxt 2 is not affected (no server islands).

Patches

When vue.runtimeCompiler is enabled, island requests whose decoded props contain a template key at any depth are rejected with an HTTP 400 and a diagnostic suggesting the author rename the prop or disable the runtime compiler. The guard is gated on the runtime compiler being enabled, so the default configuration (compiler off) is unaffected and legitimate props that merely contain a template field (for example CMS content) continue to render. A render key is not rejected: island props arrive as JSON, so a render value can only be an inert string, which Vue ignores.

Fixed in nuxt@4.5.1 and backported to nuxt@3.21.10.

Workarounds

Upgrade to nuxt@4.5.1 or nuxt@3.21.10. If you cannot immediately upgrade, you can mitigate by:

  1. Ensure vue.runtimeCompiler is set to false (the default).
  2. Do not forward island props into <component :is>, resolveDynamicComponent, or h() without sanitization.
  3. As a defense-in-depth measure, deploy a WAF rule on /__nuxt_island/ that URL-decodes and JSON-parses the props value and blocks any object property named template or render in the decoded island props, inspecting both query and body for all methods. Note: this only covers direct and browser-originated island requests; initial-SSR internal island renders do not transit the edge and a WAF alone does not close the vector.

Severity

  • CVSS Score: 8.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Nuxt: Unauthenticated CPU exhaustion parsing and hashing the Nuxt island endpoint body before hash validation

CVE-2026-71321 / GHSA-9pgf-384g-p7mv

More information

Details

Impact

The internal island renderer endpoint (/__nuxt_island/...) decodes and hashes attacker-controlled request input before it validates the URL-resident hash. An unauthenticated POST /__nuxt_island/<name>_<anything>.json with a large JSON body (for example ~4.6 MB / 150k keys) is fully read, destr-parsed, and run through ohash before the request is rejected with a 400. Because Nitro runs on a single event loop, this both wastes CPU on the doomed request and delays every concurrent request. A low request rate is enough to degrade or stall the server. No valid hash and no authentication are required.

Patches

Fixed in nuxt@4.5.1 and nuxt@3.21.10. The island handler now enforces a raw body-size cap (413) and a JSON nesting-depth cap (400) before parsing or hashing, so oversized or deeply nested input is rejected cheaply.

Workarounds

Put a small request-body limit in front of /__nuxt_island/ at your reverse proxy / edge (islands legitimately send only a compact props payload), or disable server components if unused.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

nuxt/nuxt (nuxt)

v4.5.1

Compare Source

⚠️ This is a security release. We recommend upgrading as soon as possible with npx nuxt upgrade --dedupe.

It fixes server-side RCE and unauthorized component instantiation via server island props, a route rule authorization bypass, server component DoS, cross-user payload disclosure on cached pages, and dev server path disclosure. Refreshing your lockfile also pulls in @nuxt/devtools@3.3.1, which fixes a separate critical development-only RCE.

If you already upgraded for the earlier route rule advisory (CVE-2026-53721), you still need this release: one of the fixes addresses a regression introduced by that fix.

If you use the cache, swr or isr route rules, purge any CDN or edge cache after upgrading; a leaked _payload.json may already be cached upstream.

Full details: Nuxt Security Patch Releases and GitHub Security Advisories.

👉 Changelog

compare changes

🔥 Performance
  • nitro: Replace island teleports in a single html pass (#​35515)
  • nuxt: Add vue.optionsApi and disable it for v5+ (#​35791)
  • nuxt: Without pages, skip client plugins that require routing (#​35794)
  • nuxt: Skip payload revival plugin when ssr: false (#​35782)
🩹 Fixes
  • nitro: Read rspack dev output fs lazily for server entry (#​35740)
  • rspack,webpack: Resolve loaders and runtime deps from nuxt dirs (#​35568)
  • nuxt: Return global route for useRoute in detached effect scope (#​35659)
  • nuxt: Ignore custom name or path when reusing an existing page in pages:extend (#​35661)
  • nuxt: Render client components in nested server components (#​35669)
  • nuxt: Preserve explicit useFetch method inference (#​35671)
  • nuxt: Revalidate cached route payloads instead of using force-cache (#​35672)
  • nuxt: Correct default export detection in plugin metadata (#​35676)
  • nuxt: Clear hide/reset timeouts in set() (#​35534)
  • kit,nuxt,rspack,schema,webpack: Add .mts file extension in resolver (#​33845)
  • nuxt: Preserve trailing slash in NuxtLink href when unset (#​35501)
  • nuxt: Don't cross-pollute useAsyncData cache on reactive key change (#​35656)
  • nuxt: Filter plugin dependencies by build target (#​35682)
  • nuxt: Reload real page module on HMR of JSX render-function pages (#​35678)
  • nuxt: Resolve @unhead/vue/* from nuxt's dependency tree (#​35690)
  • kit: Surface module load errors instead of masking as missing (#​35497)
  • nuxt: Type auto-imported $fetch with nitro's $Fetch (#​35704)
  • nuxt: Don't reference app config sources in shared and node tsconfigs (#​35673)
  • vite: Resolve SSR inlined CSS module class name mismatch (#​35610)
  • nuxt: Generate layout types even when pages module is disabled (#​35717)
  • nitro: Skip resource hints for stylesheets already rendered as blocking links (#​35691)
  • kit: Dedupe layers that are both auto-scanned and explicitly extended (#​35712)
  • nuxt: Don't apply scroll behaviour after a subsequent nav (#​35719)
  • vite: Ensure server sourcemap-preserver plugin actually runs (#​35680)
  • vite: Preserve css suffix when extracting ssr inline styles (#​35714)
  • nuxt: Watch external component directories in development (#​35652)
  • nuxt: Don't exclude client entry module from style extraction (#​35720)
  • nuxt: Amend cleanup command in NUXT_B7014 error message (#​35735)
  • nuxt: Only pull in vue-router when there are island pages (#​35739)
  • vite: Suppress external warnings for internal vite-node paths (#​35744)
  • nuxt: Use scope-aware oxc parser for auto-imports (#​35743)
  • nuxt: Sync layout meta during middleware on SSR (#​35633)
  • nitro: Add alias for h3 that pins it to the version nuxt depends on (#​35774)
  • nuxt: Preserve query params in cached payload extraction (#​35696)
  • nuxt: Mirror runtime route tree in generated typed-router types (#​35788)
  • nuxt: Warn when an imports preset from cannot be resolved (#​35799)
  • kit: Avoid mutating layer configs when resolving options (#​35729)
  • nuxt: Convert inline route rules exactly or drop with a warning (#​35455)
  • nitro,nuxt,vite: Dedupe and normalise global css links in dev (#​35834)
  • vite: Register template HMR plugin on dev servers (929c6c138)
  • nuxt: Remove dev error overlay when error is cleared (#​35821)
  • rspack,webpack: Resolve bundled postcss defaults from builder (#​35823)
  • schema: Normalise slashes in app.buildAssetsDir (#​35833)
  • nitro: Bound island props and v-for to prevent unauthenticated DoS (4e35ae9ba)
  • nitro: Confine runtime payload cache to prerendering (ac9b41a36)
  • nuxt: Case-fold route rule keys to match folded lookups (ad624a75a)
  • nitro: Require loopback peer for chrome devtools workspace endpoint (0769c4f9b)
  • nuxt: Reject reserved template island prop under runtime compiler (ee6c84633)
  • nuxt: Reject top-level as prop for islands (581651ff3)
💅 Refactors
  • nuxt: Use tick based debounce for asyncData executes (#​34151)
  • kit,nuxt: Replace semver with verkit (#​35713)
  • rspack,webpack: Use DI model to split builders (#​35751)
📖 Documentation
  • Add dev container setup guide (#​35665)
  • Fix dev container setup guide (#​35666)
  • Add explanation of 200.html and 404.html SPA fallbacks (#​34483)
  • Expand payload extraction documentation (#​35648)
  • Clarify NuxtLink componentName is the internal (devtools) name (#​35658)
  • Add example for components dir pattern option (#​35663)
  • Require a single root element (#​35677)
  • Add reason for why you should never import Vue app code in nitro code (#​34481)
  • Document disabling code-splitting with codeSplitting: false (#​35683)
  • Document nuxt-client caveat for non-SFC components (#​35654)
  • Clarify favicon does not use cdnURL by default (#​35681)
  • Standardize section order and headings across docs (#​35685)
  • Clarify onPrehydrate example comment (#​35684)
  • Add useId as a known limitation of nuxt island (#​35693)
  • Recommend status over pending in data fetching (#​35694)
  • Fill gaps in API minimalVersion badges after #​34485 (#​35708, #​34485)
  • Explain dynamic asset paths (#​35695)
  • Document runtimeConfig env var casting edge cases (#​35709)
  • Clarify module dependency resolution (#​35718)
  • Add more writing guidelines (#​35662)
  • Add note with alternatives to using remote layers (#​35721)
  • Use nuxt rather than nuxi (8891e179c)
  • Document relative baseURL workarounds (#​34004)
  • Warn about runtimeCompiler security best practices (449b63ab1)
  • Warn about validating server component props (2c981cb07)
📦 Build
  • nitro: Re-export type from augments to preserve module (dac937675)
  • nuxt: Remove .ts file extension from runtime/ imports (#​35689)
  • ui-templates: Commit generated ui template files (#​35770)
🏡 Chore
  • Add extension 🤦 (d595fb3d4)
  • Move to pnpm catalogs (#​35748)
  • Update knip config, resolve issues, and run in ci (#​35742)
  • Ignore @nuxt/telemetry in knip (9824d4f10)
  • ui-templates: Pass config file path to unocss (34e7a810d)
  • Allow regenerating lockfile in release script (c31389df3)
  • nuxt: Bump @nuxt/devtools to v3.3.1 (#​35815)
  • Ensure types are setup before unit tests (784d8f700)
  • Simplify knip configuration (#​35827)
✅ Tests
  • Reproduce duplicate CSS in shared chunks (#​35649)
  • Prepare fixtures automatically before fixture and e2e runs (e8b3e6411)
  • Improve and refactor basic fixture (#​35687)
  • Slim down client-only, chunk-error and axis-independent suites (#​35706)
  • Do not run type checking when benchmarking nuxt build (6355f3bc9)
  • kit: Scope loadNuxt temp dir so it doesn't delete sibling fixtures (37301dd51)
  • Guard against transient undefined _route in gotoPath (ca92d082b)
  • Retry fixture prepare on transient ENOTEMPTY (3a6b59f96)
  • Raise route-HMR polling timeout to reduce e2e flakiness (01dc27b7e)
  • Update bundle size snapshot (30d24817c)
🤖 CI
  • Rebalance shards and drop non-vite windows fixtures (#​35700)
  • Warm windows dependency cache on main (#​35730)
  • Run knip in default and production modes (#​35745)
  • Run knip on pull requests (d620aa972)
  • Prepare tests (c7bf7f738)
  • Also prepare tests in knip job (58f68bd64)
  • Check internal docs links on pull requests and all links weekly (#​35767)
❤️ Contributors

v4.5.0

Compare Source

4.5.0 is the next minor release.

📣 Some News

Preparing for Nuxt 5

A good chunk of this release is (hopefully) invisible plumbing for Nuxt 5. We've moved onto the latest major versions of several core dependencies (unhead v3, unctx v3, and Vite 8), switched the framework's own build over to tsdown, and introduced a stable nuxt/* build output contract with dev exports so that type-checking in the Nuxt monorepo works without a build step (#​35463, #​35605).

Much of this is working to shrink the gap between v4 and v5 internally, so that the migration will be as boring as possible.

[!TIP]
If you want to test some of the breaking changes of Nuxt v5, you can already opt in with future.compatibilityVersion: 5. Keep an eye on the Upgrade Guide for details as they land.

With the release of Nuxt v4.5, our focus as a team will turn to stabilising Nuxt v5 and creating compatibility utilities to make the upgrade as smooth as possible.

Nuxt 3 End-of-Life

Nuxt 3 reaches end-of-life on July 31, 2026, so this is one of the last few 3.x releases we'll ship. If you're still on v3, now is a great time to move across. Most people told us the v3 to v4 upgrade was smooth, and we've kept the upgrade guide up to date.

Alongside v4.5.0 we're publishing a maintenance patch for the 3.x line (v3.21.9) with the compatible bug fixes and smaller improvements from this release backported. The headline items here (Vite 8, Rspack 2, unhead v3, unctx v3) are major upgrades and stay v4-only, so 3.x remains stable as it approaches end-of-life.

👀 Highlights

Nuxt 4.5 is a big one. This release ships three major upgrades to the build layer (Vite 8, Rspack 2, and a brand new Rsbuild-powered pipeline for the Rspack builder), an experimental SSR streaming mode, a handful of new composables and conventions, and a lot of groundwork that brings us closer to Nuxt 5.

There's a lot here, so grab a coffee. ☕️

⚡️ Vite 8

Nuxt now runs on Vite 8 (#​34256). This brings faster cold starts, the latest Rolldown-powered internals, and many upstream improvements from the Vite team.

For most apps this is a transparent upgrade. If you have custom Vite plugins or config, it's worth skimming the Vite migration guide to check for anything that affects you.

[!WARNING]
Vite 8 is a major version bump. If you depend on Vite directly (custom plugins, vite.config tweaks, or ecosystem plugins that pin a Vite version), make sure those are compatible before upgrading in production.

🦀 Rspack 2 and Rsbuild

If you use the Rspack builder, this release is a substantial upgrade. We've moved to Rspack 2 (#​34929), which is faster and lighter, and rebuilt the builder on top of @rsbuild/core (#​35489).

The public surface stays the same. You still opt in with builder: 'rspack' and the existing rspack:* hooks continue to work:

// nuxt.config.ts
export default defineNuxtConfig({
  builder: 'rspack',
})

Under the hood, though, a lot has changed for the better:

  • The dev server now runs in middleware mode via Rsbuild, replacing webpack-dev-middleware and webpack-hot-middleware (#​35575).
  • We use an Rspack-specific Vue loader for correct SSR scoped-style ids and stricter ESM resolution (#​35566).

[!NOTE]
This is the foundation for first-class Rsbuild support. We kept the builder named rspack for now so nothing breaks, but the internals are now Rsbuild all the way down.

🌊 Experimental SSR Streaming

This is one I'm particularly excited about. You can now enable SSR streaming to dramatically improve Time to First Byte (#​34411). Instead of buffering the whole rendered page and sending it in one go, Nuxt flushes the HTML shell (your <head>, styles, preload hints, and entry scripts) immediately, then streams the body as Vue renders it.

// nuxt.config.ts
export default defineNuxtConfig({
  experimental: {
    ssrStreaming: true,
  },
})

Streaming is automatically disabled for bots and crawlers so search engines still receive fully-rendered HTML. You can tune which user agents count as crawlers, and you can opt individual routes out:

// nuxt.config.ts
export default defineNuxtConfig({
  experimental: {
    ssrStreaming: {
      botRegex: /googlebot|bingbot|my-internal-crawler/i,
    },
  },
  routeRules: {
    '/no-stream/**': { streaming: false },
  },
})

There's one thing worth understanding before you turn it on. Because streaming commits the HTTP status and headers with the very first byte, anything that mutates the response after rendering has begun (a setResponseStatus() in a <script setup>, a cookie write during middleware, and so on) can't reach the client. Nuxt handles the common cases for you: routes with redirect, cache, isr, swr, noScripts, or ssr: false rules automatically fall back to the buffered renderer, and in development we log a warning naming any dropped mutations so nothing fails silently.

[!WARNING]
SSR streaming is experimental and off by default. It could be great for content-heavy routes where TTFB matters, but test it against your app's response-mutating logic (status codes, headers, cookies) before shipping it widely. The experimental features docs cover the fallback rules and caveats in detail.

📖 SSR streaming documentation

🩺 Stable Error Codes

This one I'm really happy about. Nuxt now has a stable error code system (#​35429). Warnings and errors raised during build and at runtime now carry a stable code (like NUXT_E1001 or NUXT_B5001), a short explanation of why it happened, and a concrete fix to try.

Every code is greppable and bookmarkable, and the ones that need more than a one-line fix link straight to a dedicated docs page. For example, the classic "a composable was called outside a Nuxt context" now surfaces as NUXT_E1001 with the why/fix inline and a docs page explaining the context rules and how to use runWithContext().

To keep production output lean, the verbose why/fix text is stripped from production builds, leaving just the stable code.

This is the foundation for much better error messages across Nuxt, and we'll keep migrating existing warnings and errors onto it over the coming releases. If you've ever squinted at a cryptic Nuxt message, this is for you.

🎨 useLayout Composable

There's a new useLayout composable for reading the layout that's been resolved for the current route (#​35623). Previously there was no clean, reactive way to ask "which layout is this page using?" from within a component.

<!-- app/components/LayoutBadge.vue -->
<script setup lang="ts">
const layout = useLayout()
</script>

<template>
  <span>Current layout: {{ layout }}</span>
</template>

It returns a read-only computed ref, so it stays in sync as you navigate or as route rules and definePageMeta change the resolved layout.

📖 useLayout documentation

🪟 Named Views

Nuxt now supports named views through a filename convention (#​35123). If a parent page renders more than one <NuxtPage> outlet, you can give each outlet a name and provide a sibling page file for it using the name@view.vue convention:

# Directory Structure
-| pages/
---| parent/
-----| child.vue
-----| child@sidebar.vue
---| parent.vue
<!-- pages/parent.vue -->
<template>
  <div>
    <NuxtPage />
    <aside>
      <NuxtPage name="sidebar" />
    </aside>
  </div>
</template>

Navigating to /parent/child renders child.vue into the default outlet and child@sidebar.vue into the sidebar outlet. This has actually been possible in Vue Router for a long time; this release wires it up to Nuxt's file-based routing.

[!NOTE]
definePageMeta is read from the default route file only, and per-view rendering modes aren't supported (the parent page's mode applies to the default view).

📖 Named views documentation

🚦 enabled Option for useFetch and useAsyncData

You can now gate data fetching with a reactive enabled option (#​33260). While enabled is false, every execution is blocked (the initial fetch, execute/refresh, and watch triggers), and if you flip it from true to false mid-flight, the in-flight request is cancelled without clearing your existing data.

<script setup lang="ts">
const query = ref('')

const { data } = await useFetch('/api/search', {
  query: { q: query },
  // Only fetch once the user has typed something
  enabled: () => query.value.length > 2,
})
</script>

This is perfect for dependent or conditional queries, where you don't want to fire a request until some precondition is met. It pairs naturally with a getter or a ref, so it stays reactive.

📖 useAsyncData documentation

🔗 NuxtLink Prefetch Control for Custom Slots

When you use <NuxtLink> with the custom prop, Nuxt no longer attaches prefetch handlers for you, because it can't know how you've structured your markup. To make that ergonomic, the slot now exposes everything you need to wire prefetching up yourself (#​34539):

<template>
  <NuxtLink
    v-slot="{ href, navigate, prefetch, prefetched, shouldPrefetch }"
    to="/about"
    custom
  >
    <a
      :href="href"
      :class="{ 'is-prefetched': prefetched }"
      @click="navigate"
      @pointerenter="shouldPrefetch('interaction') && prefetch()"
      @focus="shouldPrefetch('interaction') && prefetch()"
    >
      About page
    </a>
  </NuxtLink>
</template>

You get prefetch to trigger it, prefetched to know whether it's already happened (great for a prefetched class), and shouldPrefetch to respect the user's connection and config.

📖 NuxtLink documentation

⚡️ Forwarded Preload Hints on Prefetch

Here's another one we'd love you to try. When you prefetch a link to a route with payload extraction, Nuxt already primes the destination's data and chunks. With the new opt-in `experimental

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the chore label Aug 7, 2026
@renovate
renovate Bot requested a review from danielroe as a code owner August 7, 2026 06:22
@renovate renovate Bot added the dependencies label Aug 7, 2026
@netlify

netlify Bot commented Aug 7, 2026 •
edited
Loading

Copy link
Copy Markdown

❌ Deploy Preview for friendly-lamington-fb5690 failed. Why did it fail? →

Name Link
🔨 Latest commit 6f2a244
🔍 Latest deploy log https://app.netlify.com/projects/friendly-lamington-fb5690/deploys/6a7579b20af56e0008cd11eb

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@danielroe danielroe Awaiting requested review from danielroe danielroe is a code owner

Assignees

No one assigned

Labels

chore dependencies

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants