CVE-2026-53721: Nuxt: auth bypass via URL case-sensitivity mismatch

GHSA-mm7m-92g8-7m47 HIGH
Published June 16, 2026
CISO Take

CVE-2026-53721 is an authorization bypass in Nuxt where a mismatch between the case-sensitive routeRules matcher and vue-router's default case-insensitive matching allows unauthenticated attackers to skip appMiddleware entirely by altering the casing of any static URL segment — for example, requesting /Admin/dashboard instead of /admin/dashboard. Using routeRules.appMiddleware as an access gate is a documented Nuxt pattern, meaning many production deployments are affected as built, not just misconfigured ones. With 5,435 downstream npm dependents and an EPSS in the 88th percentile the exploitable surface is broad, even without confirmed active exploitation. Organizations on Nuxt 4.x should upgrade to 4.4.7 immediately (3.21.7 for v3); the fastest short-term fix is moving security-critical middleware from routeRules.appMiddleware to definePageMeta or enforcing authorization at the API layer.

Sources: NVD EPSS GitHub Advisory ATLAS

What is the risk?

MEDIUM-HIGH. Exploitation requires no credentials and no tooling — changing one URL path segment to mixed case is trivially automatable. The precondition, using routeRules.appMiddleware as an authorization boundary, is explicitly recommended in Nuxt's own documentation, making it realistic that a meaningful share of the 5,435 dependent packages expose this surface. The server returns fully SSR-rendered output including any useFetch and useAsyncData payloads, so a successful bypass exposes backend data, not merely a page shell. No public proof-of-concept exploit or confirmed in-the-wild exploitation is known, which moderates the urgency from critical to high.

How does the attack unfold?

Reconnaissance
Attacker probes the Nuxt application to enumerate protected routes and confirm that authorization is enforced via routeRules middleware rather than at the API layer.
AML.T0006
URL Case Manipulation
Attacker crafts a request to the protected path with one or more static segments in modified case (e.g., /Admin/dashboard) to exploit the case-sensitivity disagreement between vue-router and the routeRules matcher.
AML.T0049
Middleware Bypass
Nuxt's routeRules lookup returns no match for the case-modified path, causing the appMiddleware authorization guard to be silently skipped on both SSR and client navigation.
AML.T0107
Unauthorized Data Access
Server completes full SSR render and returns the protected page including all useAsyncData payloads — API keys, user records, model configuration, compliance data — to the unauthenticated attacker.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Anthropic Python npm >= 4.0.0, < 4.4.7 4.4.7
3.6K 5.4K dependents Pushed 6d ago 91% patched ~2d to patch Full package profile →

Do you use Anthropic Python? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.0%
chance of exploitation in 30 days
Higher than 12% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

5 steps
  1. Patch immediately: upgrade to nuxt@4.4.7 (Nuxt 4.x) or nuxt@3.21.7 (Nuxt 3.x backport).

  2. Workaround A — set router.options.sensitive = true in nuxt.config to make vue-router match case-sensitively; note this changes all route-matching behavior app-wide and may break existing routes.

  3. Workaround B (preferred short-term): migrate security-critical middleware from routeRules.appMiddleware to definePageMeta({ middleware: [...] }) on each protected page component; this binding is tied to the matched route record and is immune to this bypass.

  4. Defense-in-depth (mandatory regardless): enforce authorization at the API and data-fetching layer — server middleware, API route guards, or session checks inside useAsyncData — this is the correct architectural boundary and should never rely solely on frontend route guards.

  5. Audit exposure: grep your Nuxt config and routeRules definitions for any appMiddleware keys to enumerate affected routes; prioritize those serving sensitive data.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15 - Accuracy, robustness and cybersecurity
ISO 42001
8.4 - AI system design and development
NIST AI RMF
MANAGE 2.2 - Risk treatment — response to identified AI risks
OWASP LLM Top 10
LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-53721?

CVE-2026-53721 is an authorization bypass in Nuxt where a mismatch between the case-sensitive routeRules matcher and vue-router's default case-insensitive matching allows unauthenticated attackers to skip appMiddleware entirely by altering the casing of any static URL segment — for example, requesting /Admin/dashboard instead of /admin/dashboard. Using routeRules.appMiddleware as an access gate is a documented Nuxt pattern, meaning many production deployments are affected as built, not just misconfigured ones. With 5,435 downstream npm dependents and an EPSS in the 88th percentile the exploitable surface is broad, even without confirmed active exploitation. Organizations on Nuxt 4.x should upgrade to 4.4.7 immediately (3.21.7 for v3); the fastest short-term fix is moving security-critical middleware from routeRules.appMiddleware to definePageMeta or enforcing authorization at the API layer.

Is CVE-2026-53721 actively exploited?

No confirmed active exploitation of CVE-2026-53721 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-53721?

1. Patch immediately: upgrade to nuxt@4.4.7 (Nuxt 4.x) or nuxt@3.21.7 (Nuxt 3.x backport). 2. Workaround A — set router.options.sensitive = true in nuxt.config to make vue-router match case-sensitively; note this changes all route-matching behavior app-wide and may break existing routes. 3. Workaround B (preferred short-term): migrate security-critical middleware from routeRules.appMiddleware to definePageMeta({ middleware: [...] }) on each protected page component; this binding is tied to the matched route record and is immune to this bypass. 4. Defense-in-depth (mandatory regardless): enforce authorization at the API and data-fetching layer — server middleware, API route guards, or session checks inside useAsyncData — this is the correct architectural boundary and should never rely solely on frontend route guards. 5. Audit exposure: grep your Nuxt config and routeRules definitions for any appMiddleware keys to enumerate affected routes; prioritize those serving sensitive data.

What systems are affected by CVE-2026-53721?

This vulnerability affects the following AI/ML architecture patterns: SSR web frontends for AI services and dashboards, API proxy layers built on Nuxt, AI governance and compliance portals, Admin UIs fronting LLM inference APIs.

What is the CVSS score for CVE-2026-53721?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

SSR web frontends for AI services and dashboardsAPI proxy layers built on NuxtAI governance and compliance portalsAdmin UIs fronting LLM inference APIs

MITRE ATLAS Techniques

AML.T0006 Active Scanning
AML.T0049 Exploit Public-Facing Application
AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Art. 15
ISO 42001: 8.4
NIST AI RMF: MANAGE 2.2
OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

## 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`](https://github.com/nuxt/nuxt/commit/07e39cd6f26e407b4192b7865bd17bc44536b9bb)) and backported to `nuxt@3.21.7` (commit [`3f3e3fa7`](https://github.com/nuxt/nuxt/commit/3f3e3fa7b5eec8e495f4f8ce0a54813a8875a11e)). 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: 1. Setting `router.options.sensitive = true` so vue-router matches case-sensitively (this changes route-matching behaviour app-wide). 2. Moving security-critical middleware off `routeRules.appMiddleware` and onto `definePageMeta({ middleware: [...] })` on the protected page components, which is bound to the matched record. 3. 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.

Exploitation Scenario

An attacker probing a Nuxt-based AI threat intelligence platform observes that GET /admin/dashboard returns a 302 redirect to /sign-in when accessed unauthenticated. The attacker issues a request to /Admin/dashboard with the first segment capitalized. Nuxt's vue-router matches the route record case-insensitively and proceeds with SSR; however, the routeRules lookup for the exact string /Admin/dashboard returns no entry, so the configured appMiddleware auth guard is never added to the middleware execution set. The server completes a full SSR render — executing all useAsyncData calls including database queries for premium user data, API keys, and compliance evidence — and returns the complete HTML response with embedded JSON payload to the unauthenticated attacker. No credentials, tokens, or prior reconnaissance beyond knowing the route path are required.

Weaknesses (CWE)

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.

  • [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, denylis

Source: MITRE CWE corpus.

Timeline

Published
June 16, 2026
Last Modified
June 16, 2026
First Seen
June 16, 2026

Related Vulnerabilities