GHSA-vjh5-4x84-xrqp: Npm/@nuxt/nitro-server vulnerability

Published Oct 22, 2026
·
Updated

Impact

With the default router.options.sensitive: false, Nuxt's page router resolves routes case-insensitively, so /Admin renders the same page as /admin. On the server, however, route rules were resolved with Nitro's route-rule matcher, which matches keys case-sensitively. A request whose path differs from a rule key only in letter case therefore rendered the page with none of that rule applied.

Earlier fixes (GHSA-mm7m-92g8-7m47, GHSA-hxvh-4h3w-prp9) case-folded the route rules that the Nuxt app itself reads, such as appMiddleware. This advisory covers the rules applied on the server:

- redirect: a rule used to send visitors away from a page, such as '/admin/': { redirect: '/login' }, was skipped, and the page and its server-fetched data were rendered instead. - headers: per-route response headers, including security headers such as Content-Security-Policy or X-Frame-Options, were not sent. - proxy: the request was not proxied. - ssr: false and noScripts: the page was server-rendered, or shipped scripts, despite the rule. - getRouteRules(event) (auto-imported, or from nuxt/server) and matchRouteRules from nuxt/server returned no rules for the case variant.

ts export default defineNuxtConfig({ routeRules: { '/admin/': { redirect: '/login' }, }, })

With this configuration, /admin/secret redirects to /login, but /Admin/secret rendered app/pages/admin/secret.vue.

Mitigating factors

- Applications that set router.options.sensitive: true in nuxt.config are not affected, because their pages are only served for the exact case of the route. - Access checks performed in server middleware, route middleware attached with definePageMeta, or in the page's data fetching are not affected. The issue only affects protections that rely on a server-side route rule matching the request path.

Affected versions

nuxt <4.6.2, including all Nuxt 3 releases, and @nuxt/nitro-server <4.6.2.

Patches

Fixed in nuxt@4.6.2. Nuxt 3 reached end of life on 31 July 2026 and will not receive a fix.

Nuxt now resolves server-side route rules itself, decoding and case-folding both the rule keys and the request path unless router.options.sensitive is set, and applies the result to Nitro's redirect, headers and proxy handling, the renderer, and the getRouteRules / matchRouteRules helpers.

When routing is case-insensitive, patched releases change some behaviour:

- Route rules also apply to case variants of server API routes. For example, /API/x now matches a /api/ proxy or headers rule. - Rule keys that differ only in letter case now resolve to the same path on the server, and the later key takes precedence.

The following are not changed by this fix:

- cache and swr response caching is attached to server routes by Nitro's router, which matches case-sensitively. A case variant is still rendered with its route rules applied, but its response is not cached. - Rules that a deployment preset compiles into platform configuration (for example Vercel's config.json or Netlify's redirects and headers) are matched by the platform. Once a request reaches the Nuxt server, the rules are applied as described above. - If sensitive is set only in app/router.options.ts, the server follows the nuxt.config value. In that configuration route rules can only apply to more paths, never fewer.

Workarounds

Upgrade to nuxt@4.6.2. If you cannot upgrade, including on Nuxt 3:

1. Set router: { options: { sensitive: true } } in nuxt.config, so pages are only served for the exact case of their route. 2. Alternatively, enforce access control in server middleware or route middleware rather than relying on a redirect route rule, and set security headers for every response rather than per route.

Affected Software

4 affected componentsFixes available
npm/@nuxt/nitro-server>=3.20.0<4.0.0
npm/@nuxt/nitro-server>=4.2.0<4.6.2
4.6.2
npm/nuxt>=3.0.0<4.0.0
npm/nuxt>=4.0.0<4.6.2
4.6.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@nuxt/nitro-server to a version that resolves this vulnerability.

    Fixed in 4.6.2
  2. Upgrade

    Upgrade npm/nuxt to a version that resolves this vulnerability.

    Fixed in 4.6.2
  3. Upgrade

    Upgrade nuxt to a version that resolves this vulnerability.

    Fixed in 4.6.2
  4. Upgrade

    Upgrade @nuxt/nitro-server to a version that resolves this vulnerability.

    Fixed in 4.6.2
  5. Configuration

    Set router: { options: { sensitive: true } } in nuxt.config so pages are served only for the exact case of their route.

    Nuxt router.options.sensitive = true
  6. Compensating control

    Enforce access control in server middleware or route middleware instead of relying on a redirect route rule, and set security headers for every response rather than per route.

Event History

Oct 22, 2026
Advisory Published
via GitHub·04:59 PM
Data Sourced
via GitHub·04:59 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are affected by this behavior?

Deployments using Nuxt's default router setting, router.options.sensitive: false, are affected when they rely on server-side route rules for paths whose letter case can be varied. In that configuration, the page router treats differently cased paths as the same route while Nitro's server-side route-rule matcher does not.

2

What does an attacker need to do to bypass a route rule?

An attacker only needs to request a route using different letter case than the corresponding route-rule key, such as /Admin instead of /admin. The resulting page can render without the matching server-side rule being applied.

3

Which server-side protections or behaviors can be skipped?

A case-variant request can skip redirect, headers, and proxy rules. It can also cause routes configured with ssr: false or noScripts to be server-rendered or to ship scripts instead.

4

How can I check whether my application is exposed?

Review route rules for paths such as /admin/** and request the same paths with changed letter case, such as /Admin. Check whether expected redirects, response headers, proxying, SSR behavior, or script restrictions are absent on the case-variant request.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203