GHSA-6gq8-jgmh-3ffp: Medium severity npm/nuxt vulnerability

Summary

Nuxt compared routeRules keys against the raw request path, without decoding percent-encoding, while the router decodes parameters when it resolves a route. A request whose path is percent-encoded can therefore resolve to a page while failing to match the route rule meant to protect it, so the rule's appMiddleware never runs, including during server rendering.

Impact

For a page served through a dynamic or catch-all route, an attacker can percent-encode a character in the path to skip the rule:

ts export default defineNuxtConfig({ routeRules: { '/users/admin': { appMiddleware: 'auth' }, }, })

Requesting /users/%61dmin still renders app/pages/users/[id].vue with id decoded to admin, but the rule keyed /users/admin does not match, so auth does not run and the server renders and returns the gated page to an unauthenticated visitor. No privileges and no user interaction are required, and only ASCII characters are involved.

Purely static ASCII routes are not affected: static segments are matched without decoding, so a request for /%61dmin does not resolve to the page registered at /admin and 404s instead of rendering.

The rule keys affected are the ones carried in the app manifest and consumed by the app: appMiddleware, redirect, appLayout, ssr, prerender, and the payload flags derived from cache, isr and swr.

If you have pinned or overridden dependency versions below what your Nuxt release declares, a release outside the affected ranges can still be exposed, so do not conclude from a single reproduction that you are unaffected.

Patches

Releases from 4.4.4 and 3.21.4 are not affected, because their dependency floor requires a version of the underlying HTTP layer that normalises percent-encoding in the request path before routing, which removes the mismatch in a default install.

The comparison itself is fixed in nuxt@4.5.2 and nuxt@3.21.11: route-rule keys and lookup paths are now decoded (and, unless router.options.sensitive is set, case-folded) before they are compared. Reserved escapes such as %2F are left encoded, so decoding cannot introduce extra path segments, and paths that cannot be decoded are matched verbatim. Upgrading to those releases is recommended, since it fixes the comparison rather than relying on a dependency to normalise the input, and it also restores route rules for pages whose paths contain non-ASCII characters.

Workarounds

If you cannot upgrade, do not rely on a routeRules key alone to protect a route. Attach the middleware to the page itself, which binds it to the resolved route rather than to the raw path string:

vue <script setup lang="ts"> definePageMeta({ middleware: 'auth' }) </script>

Credits

Thanks to @sushi-gif, whose report that route rules keyed with non-ASCII paths never match the routes generated for those pages prompted the review that found this issue.