CVE-2026-71315: Nuxt route rules silently dropped for mixed-case paths, bypassing appMiddleware auth gates (incomplete fix for CVE-2026-53721)

Nuxt is an open-source web development framework built on top of Vue.js. To implement centralized security rules, authentication checks, and rendering behaviors, Nuxt relies on application-level route rules defined within the framework configuration. These rules map specific URL paths to critical settings such as authorization guards (appMiddleware), server-side rendering configurations (ssr), and caching behaviors. The routing layer processes client requests and applies these middleware definitions prior to page rendering.

The vulnerability identified as CVE-2026-71315 arises from improper case-sensitivity handling within this routing layer. It constitutes an incomplete patch for a predecessor vulnerability, CVE-2026-53721. While the client request paths are matched case-insensitively by default inside the front-end router (vue-router), the backing route rules engine fails to apply matching policies correctly when mixed-case paths are requested. This mismatch results in security-critical middleware being silently dropped.

An unauthenticated remote attacker can exploit this discrepancy to bypass administrative authentication gates and access restricted pages. Because the router matches the URL and serves the corresponding page, but the rule engine fails to register the matching security policy, the targeted page is rendered without executing the specified security middleware. This leads to a complete bypass of client-side or server-side authorization controls on the affected routes.

The core of the vulnerability lies in the structural discrepancy between how the client-side routing library (vue-router) and the matching trie structure (rou3) process URL paths. By default, Nuxt configures routing in a case-insensitive manner to ensure standard web compatibility. This means that a client request to /admin or /Admin is routed to the exact same component, typically generated from a Vue file structure such as pages/Admin.vue.

To prevent routing bypasses in previous versions (specifically CVE-2026-53721), the framework developers attempted to force case insensitivity during the rule-matching phase. They achieved this by converting the incoming client-requested path to lowercase via .toLowerCase() before querying the route rules engine. However, this normalization was only performed on one half of the lookup pair. The keys representing the compiled route rules were still stored verbatim in the rou3 matching tree.

If an application registers a route rule using a mixed-case or capitalized key, such as /Admin/**, the rule is stored in the trie with those exact uppercase characters. When a client requests /admin, the incoming path is folded to lowercase /admin and compared against the trie. Because /admin does not match /Admin/** in the case-sensitive trie engine, the lookup fails and returns an empty rule set. The framework then renders the route without enforcing the associated security controls.

The vulnerability stems from the compile-time generation of the route rules dictionary and the run-time lookup logic. The vulnerable codebase utilized a forced lowercase normalization during runtime lookups inside packages/nuxt/src/app/composables/manifest.ts:

// Vulnerable lookup logic in packages/nuxt/src/app/composables/manifest.ts
export function getRouteRules (arg: string | H3Event | { path: string }) {
  const path = typeof arg === 'string' ? arg : arg.path
  try {
    // The path was forcibly converted to lowercase, causing mismatches
    // with case-sensitive route keys registered in the router.
    return routeRulesMatcher(path.toLowerCase())
  } catch (e) {
    manifestDiagnostics.NUXT_E5003({ path, cause: e })
    return {}
  }
}

The fix implemented in commits 6199633 and ad624a7 addresses this by generating two distinct matchers during build-time compilation. The build system evaluates the application configuration to determine if router.options.sensitive is active. It then constructs a verbatim sensitiveMatcher and a case-folded foldedMatcher within packages/nitro-server/src/index.ts. If routing is case-insensitive, the keys within the foldedMatcher are normalized to lowercase during initialization.

// Patched build-time key folding in packages/nitro-server/src/index.ts
const caseSensitiveRouteRules = !!nuxt.options.router.options.sensitive
const foldRouteRuleKey = (route: string) => caseSensitiveRouteRules || typeof route !== 'string' ? route : route.toLowerCase()
 
function getRouteRulesRouter (fold: boolean) {
  const routeRulesRouter = createRou3Router<NitroRouteRules>()
  if (nuxt._nitro) {
    const foldedKeys = new Map<string, string>()
    for (const [route, rules] of Object.entries(nuxt._nitro.options.routeRules)) {
      if (route === '/__nuxt_error') { continue }
      if (validManifestKeys.every(key => !(key in rules))) { continue }
      // Key is folded to lowercase if folding is enabled
      const key = fold && typeof route === 'string' ? route.toLowerCase() : route
      if (fold) {
        const existing = foldedKeys.get(key)
        if (existing !== undefined && existing !== route && !caseSensitiveRouteRules) {
          logger.warn(`Route rules match collision...`)
        }
        foldedKeys.set(key, route)
      }
      addRoute(routeRulesRouter, undefined, key, rules)
    }
  }
  return routeRulesRouter
}

Additionally, the forced .toLowerCase() call was removed from the runtime client composable. This ensures that when case sensitivity is explicitly enabled, the original path casing is preserved, preventing structural regressions while maintaining reliable matching under default case-insensitive conditions.

To exploit this vulnerability, an attacker must identify an application that relies on Nuxt route rules to enforce middleware-level authorization. The vulnerability requires that the target application has declared route rules using mixed-case paths (e.g., /Admin/** or /SecureDash/**) and is running a vulnerable version of Nuxt. Furthermore, the routing configuration must be set to the default case-insensitive mode.

The attack relies on sending HTTP requests that trigger a mismatch inside the route engine while remaining valid in the page router. An attacker targeting a protected admin page situated at pages/Admin.vue sends an unauthenticated HTTP GET request to /admin. Because vue-router resolves paths case-insensitively, it maps /admin to the administrative page component and proceeds to execute rendering.

During this rendering phase, Nuxt queries the route rules matcher to load the configuration for /admin. The matcher folds the lookup path to /admin but queries a trie containing only /Admin/**. Finding no match, the rule engine returns empty results. The application-level security middleware (appMiddleware), which would normally intercept unauthorized requests, is never executed. The server then transmits the rendered restricted interface directly to the attacker.

The security impact of CVE-2026-71315 is rated High, with a CVSS v3.1 base score of 8.2. The primary consequence is the total bypass of application-level authorization controls, leading to unauthorized access to restricted features, administrative panels, and sensitive data. Since the bypass is executed entirely through standard client requests, exploitation requires no prior privileges or user interaction.

The vulnerability compromises the integrity of defense-in-depth architectures. When developers place authentication checks exclusively in nuxt.config.ts route rules (such as specifying token verification in appMiddleware), they assume these gates are infallible entry points. This vulnerability invalidates that assumption, exposing internal APIs and administrative workflows directly to the public internet.

Although the vulnerability does not directly allow remote code execution, the unauthorized administrative access achieved can be leveraged as a stepping stone. Attackers can abuse exposed administrative workflows to modify database records, disclose proprietary data, or compromise user sessions. The lack of public exploit code does not diminish the severity, as exploitation involves simple path manipulation.

The most effective resolution is upgrading the Nuxt dependency to a patched release. For applications running on the 3.x branch, upgrade to version 3.21.10 or higher. Applications running on the 4.x branch must upgrade to version 4.5.1 or higher. These updates ensure that compiled route rules are properly synchronized with runtime lookups.

If an immediate upgrade is not feasible, developers must normalize their configurations to mitigate the risk. Modify all routeRules declared in nuxt.config.ts to be strictly lowercase (e.g., rename /Admin/** to /admin/**). This alignment eliminates the casing mismatch between the trie keys and the runtime lookups.

Alternatively, applications can transition to case-sensitive routing by configuring router.options.sensitive: true inside the Nuxt configuration file. As a final defensive measure, avoid relying solely on global configuration rules for access control. Implement component-level authorization checks inside page setup scripts using definePageMeta or inline route guards to ensure robust protection.