CVE-2026-114132: Nuxt Route-Rule Bypass and Fixes

CVE-2026-114132 concerns a mismatch between Nuxt page routing and server-side route rules. With case-insensitive routing, a page could render through a case variant of its URL while its server rule did not match. The Nuxt maintainer advisory identifies 4.6.2 as the fixed release. This is a route-policy problem, not a disclosed remote-code-execution flaw.

Start by identifying what actually protects your data. A route-rule redirect, a security header and a server-side authorization check have different jobs. A missing redirect matters differently when the data handler independently denies the request. The practical task is to connect a rule mismatch to the behavior your application relies on, then verify that behavior in the deployed build.

One URL can pass two different matching decisions

The advisory describes page routing as case-insensitive by default while the server rule matcher used case-sensitive keys. It covers redirect, 헤더, proxy 그리고 ssr rules. It explicitly excludes access checks performed in server middleware, page route middleware attached with definePageMeta, or page data fetching from this particular matching flaw.

That exclusion should narrow an assessment, not end it prematurely. Draw the actual request path: which component chooses the page, which component selects the rule, and which component authorizes the data operation? If a denied operation stays denied, record that evidence. If the only expected barrier was a redirect, review whether page rendering or data fetching exposes a protected resource. Do not infer either outcome from a framework version alone.

Affected packages and the supported fix

그리고 GitHub-reviewed package record lists the ranges below. Inspect the resolved dependencies used by your build rather than a desired version in a manifest. The database entry was published there on October 22, 2026; the maintainer advisory and release are dated October 16. Those are different publication events, not evidence that the fix first appeared on October 22.

그리고 4.6.2 release notes include case-insensitive server route-rule matching unless routing is sensitive. Select that release or a suitable later supported release, rebuild through your normal process, and map the resulting artifact to the serving deployment. This article does not establish a vendor-specific backport or test a hosted platform’s rollout.

For an existing Nuxt 3 application, plan the migration and compatibility work instead of assuming another Nuxt 3 patch will arrive. The maintainer states that Nuxt 3 reached end of life on July 31, 2026 and will not receive this fix. While arranging the supported upgrade, apply the documented workaround that matches your application and test its consequences.

The patch aligns the rule decision before server handling

그리고 upstream patch adds a request hook that assigns resolved rules to event.context._nitro.routeRules before Nitro handles them. It also generates route-path normalization using the Nuxt routing-sensitivity setting. That is a change to the server’s rule-resolution path, not a new login system or a substitute for an authorization decision.

A useful code review follows the protected operation after matching. A rule that selects a proxy affects which service may receive a request. A header rule affects the response contract. An SSR rule affects rendering behavior. Treat each dependency as a separate acceptance condition. “The page loads” is a weak test because both the intended and unintended paths may load a page successfully.

Avoid building a production repair by lowercasing every incoming URL in unrelated middleware. That can change paths your application intentionally treats as distinct, and it does not reproduce the framework’s complete normalization and rule-merging behavior. Use the supported correction and inspect conflicting rules as part of the rollout.

A small offline model makes the mismatch visible

The Python example below models one ASCII page and one redirect rule. It starts no server, sends no requests, reads no application files and requires only the standard library. Save it as route_model.py and run python3 route_model.py. The names and output labels belong to this teaching model, not Nuxt internals.

# Offline ASCII path model, not Nuxt or Nitro code.
PAGE = '/settings'
RULES = {'/settings': {'redirect': '/login'}}

def observe(path, *, sensitive=False, aligned_rules=False):
    page_matches = path == PAGE if sensitive else path.lower() == PAGE
    if not page_matches:
        return 'not-found'
    key = path if sensitive or not aligned_rules else path.lower()
    rule = RULES.get(key)
    return 'redirect' if rule else 'page-rendered'

assert observe('/settings') == 'redirect'
assert observe('/Settings') == 'page-rendered'
assert observe('/Settings', aligned_rules=True) == 'redirect'
assert observe('/Settings', sensitive=True) == 'not-found'
assert observe('/settings', sensitive=True) == 'redirect'
print('legacy canonical:', observe('/settings'))
print('legacy case variant:', observe('/Settings'))
print('aligned case variant:', observe('/Settings', aligned_rules=True))
print('sensitive case variant:', observe('/Settings', sensitive=True))
print('Five offline routing checks passed.')

This exact fixture ran locally on October 23, 2026. All five assertions passed, with this output:

legacy canonical: redirect
legacy case variant: page-rendered
aligned case variant: redirect
sensitive case variant: not-found
Five offline routing checks passed.

The contrast is narrow but useful: the page selector can accept a path while a separate policy lookup misses it. Aligning those two decisions preserves the redirect in this model; sensitive page matching instead rejects the variant. Neither result is a Nuxt exploit reproduction or proof that a real application is patched. The example omits wildcard precedence, decoding, query strings, platform rules, authentication and data fetching.

Use a workaround deliberately, then test the real behavior

그리고 maintainer’s workaround sets router.options.sensitive 에 true in nuxt.config. Alternatively, enforce access control in middleware rather than relying on a redirect rule, and apply security headers to every response. A configuration change still needs a rebuilt and redeployed application; a local edit is not deployment evidence.

// Documented workaround location: nuxt.config.ts
// Review compatibility before changing route sensitivity.
export default defineNuxtConfig({
  router: {
    options: {
      sensitive: true,
    },
  },
})

This configuration example was not executed against a Nuxt application for this article. Before changing case sensitivity, list the inbound links and integrations that currently use mixed-case paths. Decide whether they should fail or be migrated to a canonical path. Do not restore compatibility by weakening the server-side data check; preserve that check while correcting the route behavior.

Build a regression matrix around the missing control

Use owned staging routes and synthetic accounts. Capture the first response as well as any final page after redirects, and compare the response body only to a harmless expected marker. Keep credentials and customer data out of the evidence. A complete request path can include a CDN, ingress rule, proxy and Nuxt server; record which layer produced the result.

Some behavior remains separate from the fix. The advisory’s limitations distinguish Nitro’s case-sensitive attachment of cache/swr response caching from rule application, and distinguish platform-compiled rules from rules applied after reaching the Nuxt server. A cache observation or a platform redirect therefore needs its own attribution. It is not a universal verdict on the application’s server-rule matching.

For a small team, keep the rollout record short: application build, package resolution, relevant rules, tested route variants, expected control and observed result. An inconclusive case should name its missing input. This is easier to review than a large response dump without an explanation of which boundary was exercised.

If you evaluate Penligent for authorized runtime testing, use these explicit scope and evidence requirements in your evaluation. Confirm what the workflow can observe in your staging application. This article does not demonstrate a dedicated CVE-2026-114132 detector or compare measured detection performance between products.

The video below introduces AI-assisted pentesting. It is related workflow background, not a Nuxt exploit demonstration or evidence that your deployment received the fix.

Questions to settle before closing the change

Does every affected Nuxt site expose private data?

No. Determine whether the application relies on the affected server rule and what independent data authorization remains. A rule mismatch and an observed unauthorized data response are different findings.

Can the offline script establish my fixed version?

No. It demonstrates a simplified matching invariant. Use resolved-package evidence, the deployed artifact and application-specific regression results for remediation.

Should I change only app/router.options.ts?

Use the documented workaround in nuxt.config. The advisory explains that the server follows that configuration when sensitivity is set only in app/router.options.ts. Avoid assuming a client-side setting repairs the server path.

Close the task when the intended route policy holds for the supported URL forms, protected data stays protected, and required authorized work still succeeds on the released build. A corrected package is the starting evidence; the application’s actual boundary is the acceptance test.