Skip to content

GHSA-vjh5-4x84-xrqp CVE-2026-114132

Nuxt: Server-side route rules (`redirect`, `headers`, `proxy`, `ssr`) are skipped for case-variant paths when routing is case-insensitive

Medium npm
Severity
0.0 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.42%
Chance of exploitation in the next 30 days. Higher than 36.74% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-178 Improper Handling of Case Sensitivity
CWE-863 Incorrect Authorization
Fix
Available
2 packages have a fixed version

Description

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

npm

PackageVulnerableFixed in
@nuxt/nitro-server
>= 4.2.0, < 4.6.2
4.6.2
@nuxt/nitro-server
>= 3.20.0
No fix yet
nuxt
>= 4.0.0, < 4.6.2
4.6.2
nuxt
>= 3.0.0
No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

@nuxt/nitro-server npm → 4.6.2

npm
npm install @nuxt/nitro-server@4.6.2
yarn
yarn add @nuxt/nitro-server@4.6.2
pnpm
pnpm add @nuxt/nitro-server@4.6.2

nuxt npm → 4.6.2

npm
npm install nuxt@4.6.2
yarn
yarn add nuxt@4.6.2
pnpm
pnpm add nuxt@4.6.2

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Attack vector
Network
Attack complexity
Low
Attack requirements
Present
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
Low
Integrity (vulnerable system)
Low
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-178: Improper Handling of Case Sensitivity

The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.

How to prevent it
  • Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
  • Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CWE-863: Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-9v7c-q64q-vv33
Nuxt: Dot segments in the request path bypass `server/middleware` path checks and server route rules on page routes
Medium Also affects nuxt
GHSA-xfq5-w38q-pc2x
Nuxt server islands render `useHeadSafe` input without sanitisation
Medium Also affects nuxt
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
Medium Also affects nuxt
GHSA-jjm6-p2m9-9w4x
Nuxt: Incomplete fix for GHSA-934w-87qh-qr26: a `javascript:` URL prefixed with an ASCII control character executes from `<NuxtLink>` when `pages` is disabled
Low Also affects nuxt
GHSA-7c4v-fwgw-9rf7
Nuxt dev server discloses project root and workspace UUID via the Chrome DevTools workspace endpoint
Medium Also affects nuxt
GHSA-9pgf-384g-p7mv
Nuxt: Unauthenticated CPU exhaustion parsing and hashing the Nuxt island endpoint body before hash validation
High Also affects nuxt
GHSA-9473-5f9j-94wq
Nuxt: Server-Side Remote Code Execution via Runtime Template Injection in Nuxt Server Island Props
High Also affects nuxt
GHSA-48hr-524c-v5w3
Nuxt: Unauthorized Component Instantiation via Server Island Props
Medium Also affects nuxt
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor