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 for the report.
References
samsulselfut Reporter
Summary
A client that can connect to the dev server's HMR socket can send a
nuxt:dev:client-errorevent 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.0to4.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,.envfiles, cloud credentials and other files outside the project. The same path is refused by Vite'sserver.fsallow 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-builder4.6.3, whichnuxt4.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 --tunneland 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.envsecrets.Credits
Thanks to @samsulselfut for the report.
References