GHSA-mm7m-92g8-7m47 CVE-2026-53721

Nuxt: Route-rule middleware bypass via case-sensitivity mismatch between vue-router and the routeRules matcher

High npm

Severity: 0.0 / 10; High · CVSS 4.0
Exploit chance (EPSS): 0.40%; Chance of exploitation in the next 30 days. Higher than 34.16% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-178 Improper Handling of Case Sensitivity; CWE-863 Incorrect Authorization
Fix: 4.4.7; Upgrade nuxt to this version or later

Description

Impact

Nuxt looks up routeRules for the current navigation by calling getRouteRules({ path: to.path }) from the page-router plugin and the no-pages router plugin. The compiled routeRules matcher (built on rou3) performs case-sensitive matching, while vue-router is configured with its default sensitive: false and matches paths case-insensitively.

The two routers therefore disagree on which rules apply to a given request path: vue-router still matches the page record for /Admin/dashboard, but the routeRules lookup for the same path returns no match. Any appMiddleware declared via routeRules is never added to the middleware set and never runs, on both SSR and client navigations. The same path skips other path-keyed route rules in the same way (ssr, redirect, appLayout, and the prerender / payload hints used client-side).

For applications using routeRules with appMiddleware as an authorization gate (a documented pattern), an attacker can flip the case of any static segment in a protected URL (for example /Admin/dashboard instead of /admin/dashboard) to render the protected page with the middleware skipped. The server returns the fully server-rendered page including any useFetch / useAsyncData results captured during SSR.

This is an instance of CWE-178 (Improper Handling of Case Sensitivity) leading to CWE-863 (Incorrect Authorization) for apps that treat appMiddleware as an authorization boundary.

Mitigating factors

Only affects apps that use routeRules.appMiddleware. The more idiomatic definePageMeta({ middleware }) is bound to the matched route record and is unaffected.
Nuxt route middleware is documented as an app-layer concern, not a server-side auth boundary; well-built apps enforce authorization again at the API / data-fetching layer.
Apps that explicitly set router.options.sensitive = true are not affected.

Patches

Fixed in nuxt@4.4.7 (commit 07e39cd6) and backported to nuxt@3.21.7 (commit 3f3e3fa7). The fix normalizes the path used for routeRules lookups so it matches vue-router's default case-insensitive semantics.

Workarounds

Until you can upgrade, you can mitigate by either:

Setting router.options.sensitive = true so vue-router matches case-sensitively (this changes route-matching behaviour app-wide).
Moving security-critical middleware off routeRules.appMiddleware and onto definePageMeta({ middleware: [...] }) on the protected page components, which is bound to the matched record.
Enforcing authorization at the API / data-fetching layer (which you should be doing in any case).

Credit

Reported by Anthropic / Claude through Anthropic's coordinated vulnerability disclosure process. Reference: ANT-2026-9FSEBYMC.

Affected versions

npm

Package	Vulnerable	Fixed in
nuxt	`>= 4.0.0, < 4.4.7`	`4.4.7`
nuxt	`>= 3.11.0, < 3.21.7`	`3.21.7`

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 npm → `4.4.7`

npm

npm install nuxt@4.4.7

yarn

yarn add nuxt@4.4.7

pnpm

pnpm add nuxt@4.4.7

Severity breakdown

CVSS 4.0 0.0

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

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

CVSS 3.1 8.2

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: High
Integrity: Low
Availability: 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

Advisories

nvd.nist.gov/vuln/detail/CVE-2026-53721

Packages

github.com/nuxt/nuxt

Timeline

Jun 12, 2026 Published
Jun 17, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why 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-vjh5-4x84-xrqp Nuxt: Server-side route rules (`redirect`, `headers`, `proxy`, `ssr`) are skipped for case-variant paths when routing is case-insensitive	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

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