CVE-2026-119198 in Nuxt
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, a client with TCP access to an exposed Nuxt development server can send a nuxt:dev:client-error event over the HMR socket with an absolute file path at the end of its message. The development server reads that file while building the client error report and returns its contents through the error overlay, development error channel, and terminal report, bypassing Vite's server.fs allow list. The default localhost binding limits remote exposure, cross-origin browser requests are rejected, production builds and Nuxt 3 are not affected, and no browser interaction is required. This issue is fixed in version 4.6.3.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified within the Nuxt framework versions 4.6.0 through 4.6.2 represents a significant server-side file read flaw rooted in improper input validation during the Hot Module Replacement process. As an open-source development tool built on top of Vue.js and Vite, Nuxt relies heavily on real-time communication between the client and server to facilitate rapid feedback loops for developers. The specific technical failure occurs when a connected client sends a nuxt:dev:client-error event over the HMR socket. In this scenario, an attacker who has established TCP access to the exposed development server can append an absolute file path to the end of their error message payload. Upon receiving this malformed input, the Nuxt development server attempts to read the specified local file as part of its routine for generating a client-side error report. This action bypasses Vite's built-in security mechanism known as the server.fs.allow list, which is designed specifically to restrict file system access to predefined directories and prevent arbitrary file reads during module resolution or asset serving.
The operational impact of this vulnerability allows an authenticated network attacker with local TCP connectivity to perform unauthorized information disclosure. By leveraging the absolute path injection technique, the attacker can force the development server to read sensitive files from the underlying operating system and return their contents through multiple channels, including the error overlay displayed in the browser interface, the development error channel, and the terminal report output by the server process. This effectively turns a standard debugging feature into a vector for reading arbitrary local files that may contain source code secrets, environment variables containing API keys or database credentials, configuration files with sensitive infrastructure details, or other proprietary data stored on the developer's machine. The severity of this impact is compounded by the fact that no browser interaction is required from the victim beyond having the development server running and accessible; the attack can be executed entirely through network-level interactions using standard TCP sockets.
From a classification perspective, this vulnerability aligns with CWE-200: Information Exposure, as it results in the unintended disclosure of information to an actor not authorized to access that data. It also relates closely to CWE-78: Improper Neutralization of Special Elements used in an OS Command, specifically regarding path traversal and arbitrary file inclusion via unvalidated input passed to system-level read operations. In terms of adversary tactics, this behavior corresponds to the ATT&CK technique T1083: File and Directory Discovery, where attackers probe for sensitive files on a compromised or accessible host. The vulnerability is further contextualized by CWE-294: Authentication Bypass by Capture-replay if one considers that while authentication might not be explicitly bypassed in the traditional sense, the lack of strict input validation allows an entity with network access to perform actions reserved for trusted internal processes without proper authorization checks on the file path content.
Mitigation strategies primarily involve upgrading to Nuxt version 4.6.3 or later, where this issue has been resolved through stricter validation of inputs received over the HMR socket and enhanced enforcement of Vite's security policies regarding file system access. For environments that cannot immediately upgrade, it is critical to ensure that development servers are not bound to public interfaces but remain strictly on localhost or 127.0.0.1 by default, as noted in the advisory which states that default localhost binding limits remote exposure. Additionally, developers should avoid exposing Nuxt dev servers behind reverse proxies without implementing strict access controls such as IP whitelisting or mutual TLS authentication to prevent unauthorized TCP connections from external networks. It is also important to note that this vulnerability does not affect production builds of Nuxt applications nor versions prior to 4.6.0, meaning the risk profile is largely confined to active development environments where the server is running in watch mode and accepting HMR connections.