GHSA-6gq8-jgmh-3ffp Nuxt: Route rules are matched against the raw request path, so a percent-encoded segment can bypass `appMiddleware` on dynamic and catch-all routes

• npm nuxt: >= 4.0.0, < 4.4.4 → fixed in 4.4.4 • npm nuxt: >= 3.11.0, < 3.21.4 → fixed in 3.21.4

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 `[email protected]` and `[email protected]`: 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 definePageMeta({ middleware: 'auth' }) ``` 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.