@NUXT/WEBPACK-BUILDER · GHSA-x2wv-5868-p7v2 · Package
FIX → 4.6.4
When Nuxt's webpack or rspack builder runs in dev mode, a malicious page opened in the browser can use DNS rebinding to fetch the built client JavaScript from the dev server. An attacker can read the app's compiled source, source maps, local file paths and any values inlined into the client bundle.
first public Nov 2, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Only development machines running nuxt dev with the webpack or rspack builder are exposed; the attacker's page must be opened in a browser while the dev server runs. Production builds and projects using the default Vite builder are not affected. Projects that reach the dev server through another hostname need to add it to devServer.allowedHosts after upgrading.
Not affected if production-only, static-export, vite-builder
Who cares local-dev, npm, nuxt, rspack, webpack
npm ls @nuxt/webpack-builder @nuxt/rspack-builder.When using the webpack or rspack builder, the dev server serves built client chunks to any request whose Host header matches its Origin/Referer, or that carries Sec-Fetch-Site: same-origin. After a DNS rebinding attack both headers name the attacker's hostname, so a malicious page opened while nuxt dev is running can read /_nuxt/*.js and exfiltrate the app's source. This bypasses the same-origin check added for GHSA-4gf7-ff8x-hq99, GHSA-6m52-m754-pw2g and GHSA-x6qj-4h56-5rj5.
A developer runs nuxt dev with builder: 'webpack' or builder: 'rspack' (the default config is enough; --host is not required) and opens a page on an attacker-controlled hostname, for example . The attacker then re-points that hostname at . Requests from the page now reach the dev server as same-origin requests:
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
nuxt.configbuilder: 'webpack'builder: 'rspack'viteUpgrade to 4.6.4
@nuxt/webpack-builder 4.6.4 and later within 4.x@nuxt/rspack-builder 4.6.4 and later within 4.xhttp://rebind.attacker.example:3000/127.0.0.1curl -H 'Host: rebind.attacker.example:3000' -H 'Sec-Fetch-Site: same-origin' http://127.0.0.1:3000/_nuxt/app.js
# 200, with the compiled modules
The page can read the response with fetch, which exposes the compiled source and its inline source maps, module identifiers, the developer's local filesystem paths, and any developer-controlled values inlined into the client bundle (for example through a custom DefinePlugin). With rspack, the HMR websocket also accepts connections from the rebound hostname. Private runtimeConfig is not part of the client bundle.
The attacker needs to know or guess the dev server port and to time the DNS change. Chrome 142+ and other Chromium-based browsers that enforce Local Network Access restrictions prompt before a public page can reach a loopback address.
The default Vite builder is not affected: Vite rejects unknown Host headers through server.allowedHosts. Production builds are not affected.
Fixed in @nuxt/webpack-builder 4.6.4 and @nuxt/rspack-builder 4.6.4. The dev middleware now rejects requests whose Host header is not localhost, *.localhost, an IP address, or a hostname allowed by the new devServer.allowedHosts option or by vite.server.allowedHosts, before any Sec-Fetch-Site/Origin/Referer checks. This includes devServer.host and the hosts nuxt dev allows for the addresses it listens on; nuxt dev --public allows any host, as it does with Vite. With rspack, the same list is passed to rsbuild's server.allowedHosts, which covers the HMR websocket.
If you reach the dev server through another hostname, for example through a reverse proxy, add it to devServer.allowedHosts (a leading . also allows subdomains, true allows any host).
Nuxt 3 has reached end of life and will not receive a fix.
Thanks to Anthropic for reporting this through coordinated disclosure (ANT-2026-VKRM97G5).