CVE-2026-71319: Remote Code Execution via Unauthenticated RPC in Nuxt DevTools

Nuxt DevTools exposes a bidirectional RPC (Remote Procedure Call) channel designed to assist developers in inspecting and debugging Nuxt applications directly from their browsers.\n\nThis communication channel is established automatically during development and runs on top of the Vite Hot Module Replacement (HMR) WebSocket server using the vite-hmr subprotocol.\n\nIn vulnerable versions of @nuxt/devtools (prior to 3.3.1), the RPC interface is exposed without authorization controls, origin checks, or authentication handshake protocols, presenting an unauthenticated entry point to the host system.

The core of the vulnerability lies in the lack of privilege verification on sensitive RPC methods.\n\nWhile some actions that modify the server state require a developer authentication token (devAuthToken), several administrative functions were left entirely unguarded.\n\nSpecifically, the updateOptions() and openInEditor() methods did not require any authentication token. This oversight allows an unauthenticated client connecting to the Vite HMR WebSocket to invoke updateOptions() to alter the configuration mapping for the file editor to a malicious shell command.\n\nWhen the client subsequently calls openInEditor(), the backend utilizes the launch-editor Node.js library to execute the modified editor command as a child process via child_process.spawn or child_process.exec, resulting in command injection and execution under the context of the running Node.js development server.

To understand the flaw, we examine the differences in the RPC service definition and execution flow. The following diff illustrates how the server handlers were refactored to enforce authentication.\n\ntypescript\n// In packages/devtools-kit/src/_types/rpc.ts\nexport interface ServerFunctions {\n- updateOptions: <T extends keyof NuxtDevToolsOptions>(tab: T, settings: Partial<NuxtDevToolsOptions[T]>) => Promise<void>\n- clearOptions: () => Promise<void>\n+ updateOptions: <T extends keyof NuxtDevToolsOptions>(token: string, tab: T, settings: Partial<NuxtDevToolsOptions[T]>) => Promise<void>\n+ clearOptions: (token: string) => Promise<void>\n\n- openInEditor: (filepath: string) => Promise<boolean>\n+ openInEditor: (token: string, filepath: string) => Promise<boolean>\n}\n\n\nIn the patched version, the backend explicitly verifies the user-provided token against the generated devAuthToken before proceeding with the operation.\n\ntypescript\n// In packages/devtools/src/server-rpc/general.ts\n- async openInEditor(input: string): Promise<boolean> {\n+ async openInEditor(token: string, input: string): Promise<boolean> {\n+ await ensureDevAuthToken(token)\n if (input.startsWith('./') || !ABSOLUTE_PATH_RE.test(input))\n input = resolve(process.cwd(), input)\n\n\nWithout this token validation, any local or external entity capable of establishing a WebSocket connection could modify settings and execute arbitrary commands.

An attacker can exploit this vulnerability through two main pathways: local network exposure or Cross-Site WebSocket Hijacking (CSWSH).\n\nIf a developer starts their server binding to all interfaces (e.g., 0.0.0.0), an attacker on the same local network can establish a WebSocket connection directly. Alternatively, if the server is bound to localhost, a malicious website visited by the developer can perform a CSWSH attack, exploiting the fact that browsers do not restrict cross-origin WebSocket connections.\n\nmermaid\ngraph LR\n Attacker[\"Attacker Client\"] -->|\"1. Connects with subprotocol 'vite-hmr'\"| WS[\"Vite HMR WebSocket Port\"]\n Attacker -->|\"2. Send updateOptions RPC to change editor to malicious cmd\"| WS\n Attacker -->|\"3. Send openInEditor RPC\"| WS\n WS -->|\"4. launch-editor runs command\"| OS[\"Host Operating System Command Execution\"]\n\n\nTo trigger the execution, the attacker sends two distinct JSON-RPC frames over the WebSocket protocol. The first payload registers a malicious payload in the openInEditor setting. The second payload triggers the execution of that editor command by requesting a standard project file to be opened.

Successful exploitation allows an unauthenticated remote attacker to achieve arbitrary code execution on the developer's workstation under the context of the user running the Node.js application.\n\nBecause developers often operate with elevated privileges or hold sensitive credentials (such as API keys, SSH keys, and cloud environment variables) on their workstations, a compromise of the development host has high severity.\n\nThis vulnerability is tracked as CVE-2026-71319 with a CVSS v3.1 score of 9.6, indicating critical severity due to the potential for complete host takeover.

The primary remediation strategy is upgrading @nuxt/devtools to version 3.3.1 or newer, which enforces devAuthToken validation on all sensitive endpoints.\n\nIf an immediate upgrade is not feasible, developers should disable Nuxt DevTools in their configuration file.\n\ntypescript\n// In nuxt.config.ts\nexport default defineNuxtConfig({\n devtools: {\n enabled: false\n }\n})\n\n\nAdditionally, developers should ensure that the development server binds only to loopback interfaces (such as 127.0.0.1) rather than 0.0.0.0 to minimize exposure to local network actors.