CVE-2026-119201 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, nuxt dev stores a generated appSecret in <buildDir>/app-secret, by default .nuxt/app-secret, within a directory allowed by Vite's server.fs configuration. A client with direct HTTP access to an exposed development server can fetch the file, use deriveSecret() to compute derived secrets such as the default useSession password, and forge session cookies accepted by that development server. The default localhost binding limits remote exposure, cross-origin browser reads are blocked, production builds and development servers with an explicitly configured appSecret are not affected. This issue is fixed in version 4.6.3.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified within Nuxt versions ranging from 4.6.0 to 4.6.3 represents a critical misconfiguration in the handling of sensitive cryptographic material during the development phase of web applications built with this Vue.js framework. The core technical flaw lies in the storage location and accessibility of the generated appSecret, which is written to a file within the build directory, typically located at .nuxt/app-secret by default. This specific path falls under the scope of Vite's server.fs configuration, which governs how the development server interacts with the local filesystem. In this context, the configuration inadvertently permits direct HTTP access to files that reside in directories intended for internal processing rather than public serving. Consequently, any client possessing direct network connectivity to the exposed development server can issue an unauthenticated request to retrieve this secret file directly from the web root or accessible subdirectories.
The operational impact of this vulnerability is severe due to the cryptographic implications of exposing the appSecret. This secret serves as the foundational key for deriving other sensitive values, most notably the password used by the default session management mechanism via the deriveSecret function. An attacker who successfully retrieves the appSecret can compute these derived secrets locally without any interaction with the server's runtime logic. With knowledge of the derived session passwords, an adversary is able to forge valid session cookies that are accepted as authentic by the development server. This effectively allows for complete authentication bypass in a development environment, granting unauthorized access to user sessions and potentially exposing sensitive application data or administrative functions if such features are enabled during development.
From a threat modeling perspective, this vulnerability aligns with CWE-200: Information Exposure, specifically involving the exposure of cryptographic keys through improper file permissions or server configuration. Furthermore, it maps to MITRE ATT&CK technique T1539: Steal Web Session Cookie, as the exploitation vector directly facilitates the creation and use of forged session tokens. It is important to note that the risk profile is heavily influenced by the deployment context. The default binding address for Nuxt development servers is localhost, which inherently limits remote exposure to local network users or processes running on the same host. Additionally, cross-origin browser reads are blocked by standard security policies such as Same-Origin Policy and CORS restrictions, meaning a malicious website hosted remotely cannot directly fetch this file via client-side JavaScript. Production builds are not affected because they do not utilize the development server's dynamic secret generation mechanism in the same manner, nor is an instance vulnerable if an administrator has explicitly configured a static appSecret that overrides the default behavior.
Mitigation strategies primarily involve upgrading to version 4.6.3 or later, where this issue has been resolved by adjusting how and where the appSecret is stored and served. For environments where immediate patching is not feasible, administrators should ensure that development servers are bound strictly to localhost if remote access is unnecessary, thereby preventing external network entities from reaching the server endpoint. It is also advisable to review Vite's server.fs configuration to restrict file system access only to necessary directories and to avoid exposing internal build artifacts through HTTP endpoints. In production environments, ensuring that no sensitive secrets are stored in publicly accessible paths within the static asset directory remains a fundamental security best practice regardless of framework version.