Vulnerability GHSA-r99w-jh2x-3mg9
Summary
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
Details
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/apiandserver/routes, which Nitro does not match for these paths. appMiddlewareroute rules and middleware declared withdefinePageMeta, which are matched against the resolved route.- Nuxt
3.xand4.0.0to4.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.
Related Vulnerabilities
Other vulnerabilities affecting the same packages