Nuxtに不適切な認可の脆弱性（CVE-2026-114131）

### 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.

Nuxt is an open-source web development framework for Vue.js. From 3.11.0 until 3.21.4 and 4.4.4, Nuxt compares route-rule keys with the raw request path while route resolution decodes dynamic and catch-all parameters, allowing a percent-encoded segment to resolve to a protected page without matching the routeRules entry intended for that path. As a result, appMiddleware can be skipped during server rendering and an unauthenticated requester can receive the gated page and its SSR data. The same mismatch affects app-manifest rules including redirect, appLayout, ssr, prerender, and payload flags derived from cache, isr, and swr. This vulnerability is fixed in 4.4.4 and 3.21.4.