Nuxt: Incomplete fix for GHSA-9v7c-q64q-vv33: a leading `//` in the request path bypasses `server/middleware` path checks and server route rules on page routes

Summary

Since 4.6.0, Nuxt parses a request path that starts with // as a URL with a host before rendering a page, so //x/admin renders the page at /admin. Nitro's routing, Nitro's route rules and server/middleware see the path as //x/admin, so server-side checks keyed on /admin do not apply. The fix for GHSA-9v7c-q64q-vv33 in 4.6.3 covered dot segments but not this form.

Impact

An unauthenticated attacker can bypass server-side controls that match on the request path of a page route.

A route-scoped server handler is skipped:

// nuxt.config.ts
export default defineNuxtConfig({
  serverHandlers: [{ route: '/admin', middleware: true, handler: '~~/server/admin-guard.ts' }],
})

// server/admin-guard.ts
export default defineEventHandler((event) => {
  if (!isAuthenticated(event)) {
    throw createError({ statusCode: 401 })
  }
})

With this handler, /admin returns 401, but //x/admin and ///x/admin render app/pages/admin.vue along with the data it fetches during server rendering. server/middleware that checks event.path.startsWith('/admin') is skipped in the same way.

Server-side redirect and headers route rules are also skipped, so '/admin/**': { redirect: '/login' } does not redirect //x/admin/secret, and per-route security headers such as Content-Security-Policy are not sent.

Browsers send a path such as //x/admin as written, so a plain link is enough to reach the page.

Not affected:

• API handlers in server/api and server/routes, which Nitro does not match for these paths.
• appMiddleware route rules and middleware declared with definePageMeta, which are matched against the resolved route.
• Nuxt 3.x and 4.0.0 to 4.5.x, which pass the path to the page router unchanged, so these requests 404.

Patches

Fixed in @nuxt/[email protected], which [email protected] depends on. The renderer now uses the request path exactly as Nitro matched it, so a path starting with // no longer resolves to a different page.

Workarounds

Reject request paths that start with // in a server middleware:

// server/middleware/double-slash.ts
export default defineEventHandler((event) => {
  if (event.path.startsWith('//')) {
    throw createError({ statusCode: 404 })
  }
})

A reverse proxy or CDN that merges repeated slashes before forwarding the request also removes the mismatch.

Credits

Nuxt thanks @kq5y for reporting this issue.