CVE-2026-119200 in Nuxtinfo

Summary

by MITRE • 10/29/2026

Nuxt is an open-source web development framework for Vue.js. From 4.6.0 until 4.6.3, Nuxt resolves literal or percent-encoded dot segments before rendering a page while Nitro routing, server/middleware checks, and server route rules evaluate the unresolved path. A request such as /%2e/admin can therefore render app/pages/admin.vue and its server-rendered data while checks keyed to /admin, redirects, or per-route security headers do not apply. API handlers, appMiddleware, Nuxt 3, and Nuxt 4.0.0 through 4.5.x are not affected, and exploitation requires a client that sends dot segments without browser normalization. This issue is fixed in version 4.6.3.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 10/29/2026

The vulnerability identified within the Nuxt web development framework represents a critical path traversal and access control bypass flaw rooted in inconsistent URL normalization between different layers of the application stack. Specifically, this issue affects versions ranging from 4.6.0 to 4.6.2, where the rendering engine processes literal or percent-encoded dot segments such as /%2e/admin before generating the page content. In contrast, Nitro routing mechanisms, server-side middleware checks, and explicit server route rules evaluate the raw, unresolved path string. This architectural discrepancy creates a security gap wherein an attacker can craft requests that bypass intended access controls by exploiting the difference in how these components interpret URL paths.

From a technical perspective, the core flaw lies in the order of operations during request handling. When a client sends a request with percent-encoded dot segments, such as /%2e/admin, the Nitro routing layer and associated middleware treat this path as distinct from /admin because they do not normalize the encoded characters into their literal equivalents before performing security checks or route matching. Consequently, access control lists that are keyed to the standard /admin endpoint fail to trigger for the encoded variant. However, once the request passes through these unchecked layers, Nuxt’s rendering engine resolves the dot segments and correctly identifies the target as admin.vue. This allows the application to render sensitive pages and serve server-rendered data associated with those pages, effectively circumventing middleware-based protections like authentication checks or per-route security headers that were designed to restrict access to /admin.

The operational impact of this vulnerability is significant for applications relying on Nuxt’s built-in routing and middleware systems for authorization. An attacker can exploit this inconsistency to access restricted areas of the application without valid credentials, potentially leading to unauthorized data exposure, privilege escalation, or further exploitation depending on the sensitivity of the rendered content. It is important to note that API handlers are not affected by this specific flaw, as they operate under different routing logic. Furthermore, versions prior to 4.6.0 and subsequent releases starting from Nuxt 3 through 4.5.x are immune to this issue due to their distinct handling of URL paths or earlier implementation timelines before the problematic code path was introduced in version 4.6.0.

Exploitation of this vulnerability requires specific conditions regarding client behavior. The attack relies on a client that transmits dot segments without browser normalization, as modern web browsers typically normalize percent-encoded dots into literal dots before sending requests to servers. Therefore, exploitation is most feasible through direct HTTP clients or custom scripts rather than standard user interactions via typical web browsers. This constraint limits the blast radius but does not eliminate the risk for applications exposed to automated tools or sophisticated attackers capable of crafting raw HTTP requests with encoded path segments.

To mitigate this vulnerability, organizations must upgrade immediately to Nuxt version 4.6.3 or later, where the rendering engine and routing layers have been aligned to ensure consistent normalization of URL paths before any security checks are performed. For environments unable to patch immediately due to dependency constraints, implementing a custom middleware that explicitly normalizes percent-encoded dot segments in incoming request URLs can serve as an effective compensating control. This middleware should decode %2e characters into literal dots and resolve relative path components such as . and .. before passing the cleaned URL to downstream routing or authentication logic. Additionally, security teams should review their Nitro configuration to ensure that all route rules account for normalized paths rather than raw input strings.

This vulnerability is classified under CWE-798: Use of Hard-coded Credentials if it leads to unauthorized access via bypassed auth, but more accurately falls under CWE-20: Improper Input Validation and CWE-434: Unrestricted Upload of File with Dangerous Type if file handling were involved, though primarily it aligns with CWE-611: Improper Restriction of XML External Entity Reference in the context of path traversal logic. In terms of offensive security frameworks, this behavior maps to MITRE ATT&CK technique T1078: Valid Accounts when used for privilege escalation via access control bypass, and specifically relates to path traversal mechanisms often categorized under lateral movement or initial access vectors depending on the application's role. The inconsistency in input normalization is a common pattern in web framework vulnerabilities, highlighting the necessity of rigorous URL canonicalization at every layer of request processing to prevent logic-based attacks that exploit discrepancies between security enforcement points and resource resolution engines.

Responsible

GitHub M

Reservation

10/29/2026

Disclosure

10/29/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!