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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Anthropic Python | npm | >= 4.0.0, < 4.4.7 | 4.4.7 |
Do you use Anthropic Python? You're affected.
How severe is it?
What should I do?
5 steps-
Patch immediately: upgrade to nuxt@4.4.7 (Nuxt 4.x) or nuxt@3.21.7 (Nuxt 3.x backport).
-
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.
-
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.
-
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.
-
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:
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
MITRE ATLAS Techniques
AML.T0006 Active Scanning AML.T0049 Exploit Public-Facing Application AML.T0107 Exploitation for Defense Evasion Compliance Controls Affected
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.
References
Timeline
Related Vulnerabilities
CVE-2026-45370 7.7 utcp-cli: env leak exfiltrates all agent process secrets
Same package: anthropic CVE-2026-21852 7.5 claude_code: Weak Credentials allow account compromise
Same package: anthropic GHSA-534h-c3cw-v3h9 5.5 Nuxt: local unauth IPC leaks .env secrets on shared hosts
Same package: anthropic CVE-2026-34452 Anthropic SDK: TOCTOU symlink escape in async memory tool
Same package: anthropic CVE-2026-34450 anthropic-sdk: insecure file perms expose agent memory
Same package: anthropic