Nuxt dev server arbitrary file read through client error reports

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.

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.

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.

### Summary A client that can connect to the dev server's HMR socket can send a `nuxt:dev:client-error` event whose message ends in an absolute file path. The dev server reads that file while building the error report, and its contents are returned in the error overlay, on the dev error channel, and in the report shown in the terminal. ### Impact This affects the development server only; production builds contain none of this code. Affected versions are `4.6.0` to `4.6.2`. Reading the file requires TCP access to the dev server, so the default localhost bind limits this to local processes, which can usually read the same files directly. With the dev server exposed to a network (`nuxt dev --host`, `nuxt dev --tunnel`, or a proxy onto the dev port), anyone who can reach the port can read any file the dev process can read: SSH keys, `.env` files, cloud credentials and other files outside the project. The same path is refused by Vite's `server.fs` allow list over `/_nuxt/@fs/`; the client error channel bypasses that check. No user interaction is needed and no browser is involved: a plain WebSocket client is enough, as long as it does not send `Sec-Fetch-Site: cross-site`. A web page on another origin cannot retrieve the report: the overlay and channel endpoints reject browser requests from other origins. Nuxt 3 is not affected. ### Patches Fixed in `@nuxt/vite-builder` 4.6.3, which `nuxt` 4.6.3 depends on. A client-reported error is no longer turned into a compile report, and report building for it no longer reads from the filesystem; file content now comes only from the dev server's module graph. ### Workarounds Do not expose the dev server to untrusted networks: keep the default localhost bind, and avoid `nuxt dev --host`, `nuxt dev --tunnel` and proxies onto the dev port. If the dev port was reachable from an untrusted network while a vulnerable version was running, treat any file readable by the dev process on that machine as exposed, and rotate credentials such as SSH keys and `.env` secrets. ### Credits Thanks to [@samsulselfut](https://github.com/samsulselfut) for the report.