Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Since `4.6.0`, Nuxt resolves `.` and `..` segments in the request path, including percent-encoded forms such as `%2e`, before rendering a page. Nitro's routing, Nitro's route rules and `server/middleware` see the path with those segments still in place. A request for `/%2e/admin` therefore renders the page at `/admin`, while server-side checks keyed on `/admin` do not apply. Impact An unauthenticated attacker can bypass server-side controls that match on the request path of a page route. `server/middleware` that checks `event.path` (or `event.node.req.url`) is skipped: ```ts export default defineEventHandler((event) => { if (event.path.startsWith('/admin') && !isAuthenticated(event)) { throw createError({ statusCode: 401 }) } }) ``` With this middleware, `/admin` returns 401, but `/%2e/admin`, `/.%2e/admin` and `/x/%2e%2e/admin` reach the middleware with `event.path` set to `/./admin`, `/../admin` and `/x/../admin`, and render `app/pages/admin.vue` along with the data…
Recommended action: Upgrade to 4.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When experimental.componentIslands is enabled (default in Nuxt 4), any .server.vue file under pages/ is automatically registered as a server island under the key page<routeName and exposed via the /nuxtisland/:name endpoint. Until this fix, requests through that endpoint rendered the page component directly via the SSR renderer without instantiating Vue Router, which meant route middleware declared on the page (including definePageMeta({ middleware })) did not run. For Nuxt applications that gate a .server.vue page behind route middleware as their sole auth check, an unauthenticated attacker could bypass that check by requesting /nuxtisland/page<routeName<anyhash directly and receiving the server-rendered HTML. Affected configurations All three conditions must hold for an application to be vulnerable: 1. experimental.componentIslands is enabled (the default in Nuxt 4; opt-in in Nuxt 3). 2. The application defines one or more .server.vue files under pages/, registering them as…
Recommended action: Upgrade to 4.4.6 or 3.21.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /nuxtisland/ endpoint accepts attacker-controlled props query/body parameters and renders any island component without verifying that the URL-resident hash (<Name<hashId.json) was actually issued for those inputs by <NuxtIsland. The hash is computed and embedded client-side but never validated server-side, so the same path can return materially different responses depending on the query. Island components are documented as rendering independently of route context - page middleware does not apply to them, and they are intentionally cacheable as a function of their props. This advisory does not treat that contract as a vulnerability. It treats the absence of a binding between the URL the cache keys on and the response served at that URL as one. Impact In applications where a CDN or reverse-proxy in front of the app caches /nuxtisland/ keyed by path only (ignoring query) - a documented misconfiguration class, see GHSA-jvhm-gjrh-3h93 - an attacker can prime the cache for a…
Recommended action: Upgrade to 4.4.6 or 3.21.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.