GHSA-vjh5-4x84-xrqp CVE-2026-114132
Nuxt: Server-side route rules (`redirect`, `headers`, `proxy`, `ssr`) are skipped for case-variant paths when routing is case-insensitive
- Severity
- 0.0 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- 0.42%
- Chance of exploitation in the next 30 days. Higher than 36.74% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
- Available
- 2 packages have a fixed version
Description
Impact
With the default router.options.sensitive: false, Nuxt's page router resolves routes case-insensitively, so /Admin renders the same page as /admin. On the server, however, route rules were resolved with Nitro's route-rule matcher, which matches keys case-sensitively. A request whose path differs from a rule key only in letter case therefore rendered the page with none of that rule applied.
Earlier fixes (GHSA-mm7m-92g8-7m47, GHSA-hxvh-4h3w-prp9) case-folded the route rules that the Nuxt app itself reads, such as appMiddleware. This advisory covers the rules applied on the server:
redirect: a rule used to send visitors away from a page, such as'/admin/**': { redirect: '/login' }, was skipped, and the page and its server-fetched data were rendered instead.headers: per-route response headers, including security headers such asContent-Security-PolicyorX-Frame-Options, were not sent.proxy: the request was not proxied.ssr: falseandnoScripts: the page was server-rendered, or shipped scripts, despite the rule.getRouteRules(event)(auto-imported, or fromnuxt/server) andmatchRouteRulesfromnuxt/serverreturned no rules for the case variant.
export default defineNuxtConfig({
routeRules: {
'/admin/**': { redirect: '/login' },
},
})
With this configuration, /admin/secret redirects to /login, but /Admin/secret rendered app/pages/admin/secret.vue.
Mitigating factors
- Applications that set
router.options.sensitive: trueinnuxt.configare not affected, because their pages are only served for the exact case of the route. - Access checks performed in server middleware, route middleware attached with
definePageMeta, or in the page's data fetching are not affected. The issue only affects protections that rely on a server-side route rule matching the request path.
Affected versions
nuxt <4.6.2, including all Nuxt 3 releases, and @nuxt/nitro-server <4.6.2.
Patches
Fixed in nuxt@4.6.2. Nuxt 3 reached end of life on 31 July 2026 and will not receive a fix.
Nuxt now resolves server-side route rules itself, decoding and case-folding both the rule keys and the request path unless router.options.sensitive is set, and applies the result to Nitro's redirect, headers and proxy handling, the renderer, and the getRouteRules / matchRouteRules helpers.
When routing is case-insensitive, patched releases change some behaviour:
- Route rules also apply to case variants of server API routes. For example,
/API/xnow matches a/api/**proxyorheadersrule. - Rule keys that differ only in letter case now resolve to the same path on the server, and the later key takes precedence.
The following are not changed by this fix:
cacheandswrresponse caching is attached to server routes by Nitro's router, which matches case-sensitively. A case variant is still rendered with its route rules applied, but its response is not cached.- Rules that a deployment preset compiles into platform configuration (for example Vercel's
config.jsonor Netlify's_redirectsand_headers) are matched by the platform. Once a request reaches the Nuxt server, the rules are applied as described above. - If
sensitiveis set only inapp/router.options.ts, the server follows thenuxt.configvalue. In that configuration route rules can only apply to more paths, never fewer.
Workarounds
Upgrade to nuxt@4.6.2. If you cannot upgrade, including on Nuxt 3:
- Set
router: { options: { sensitive: true } }innuxt.config, so pages are only served for the exact case of their route. - Alternatively, enforce access control in server middleware or route middleware rather than relying on a
redirectroute rule, and set security headers for every response rather than per route.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| @nuxt/nitro-server | >= 4.2.0, < 4.6.2 |
4.6.2 |
| @nuxt/nitro-server | >= 3.20.0 |
No fix yet |
| nuxt | >= 4.0.0, < 4.6.2 |
4.6.2 |
| nuxt | >= 3.0.0 |
No fix yet |
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/nitro-server npm → 4.6.2
- npm
npm install @nuxt/nitro-server@4.6.2- yarn
yarn add @nuxt/nitro-server@4.6.2- pnpm
pnpm add @nuxt/nitro-server@4.6.2
nuxt npm → 4.6.2
- npm
npm install nuxt@4.6.2- yarn
yarn add nuxt@4.6.2- pnpm
pnpm add nuxt@4.6.2
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- Low
- Integrity (vulnerable system)
- Low
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- 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
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| 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-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 |
| GHSA-48hr-524c-v5w3 Nuxt: Unauthorized Component Instantiation via Server Island Props | Medium | Also affects nuxt |
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