Summary
Nuxt DevTools in development mode exposes an unauthenticated bidirectional RPC channel through the Vite HMR WebSocket. A client that can reach the HMR endpoint may alter the editor command configuration and cause an arbitrary program to run on the developer's machine when the editor-opening function is invoked.
Affected context
The issue occurs in Nuxt development environments that enable Nuxt DevTools and expose the Vite HMR WebSocket to a reachable network. The affected RPC channel lacks authentication and origin validation, while selected methods can modify editor behavior and invoke the configured editor process. Risk depends on network exposure of the development server and the privileges of the developer's local account.
Exploit preconditions
- Attack surface: Vite HMR WebSocket used by Nuxt DevTools
- Required access: Network reachability to the development server's HMR endpoint; no application authentication is required by the affected channel
- Trigger point: RPC methods that update editor configuration and subsequently open a file
- Why exploitation is possible: The editor command is accepted through an unauthenticated RPC path and is later passed to a child-process launcher without an effective authorization check
Why this happens
The vulnerability results from missing authentication and authorization controls on sensitive development-tool RPC methods. Although other mutating operations use a development authorization token check, the affected configuration and editor-launch methods do not enforce the same control. Consequently, attacker-controlled RPC data can influence a value used to spawn a process, mapping the behavior to CWE-94: Improper Control of Generation of Code and, more broadly, to missing authentication under CWE-306.
Potential impact
- An attacker may execute an arbitrary program on the developer's machine
- Local source code, credentials, and development artifacts could be exposed
- The developer environment could be modified or compromised
- Malicious changes could be introduced into applications or build workflows
- The impact may extend to other systems accessible from the developer workstation
General mitigation guidance
Mitigation generally focuses on protecting development-server control channels and preventing remote input from influencing process execution.
Common defensive patterns include:
- Require authentication and authorization for every RPC method that changes state or launches a process
- Enforce origin and network-access controls before establishing HMR or DevTools channels
- Keep development servers bound to trusted local interfaces rather than broadly reachable addresses
- Avoid accepting arbitrary executable commands from RPC or configuration inputs
- Use a fixed, allowlisted editor selection instead of passing attacker-controlled strings to process-launch APIs
- Run development tooling with least-privilege accounts and isolated environments
- Treat HMR and DevTools endpoints as privileged local administration surfaces
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis for WebSocket handlers that expose RPC methods without authentication or origin validation
- Code review checks for process-spawning APIs receiving values from RPC, HTTP, or configuration input
- Review of authorization coverage to ensure all mutating methods use the same access-control mechanism
- Network monitoring for unexpected connections to development HMR ports
- Policy enforcement that prevents development servers from being exposed beyond trusted interfaces
- Automated security review tools that flag unauthenticated control channels and unsafe child-process invocation
