Summary
@nuxt/webpack-builder and @nuxt/rspack-builder dev server same-origin check bypassed when Sec-Fetch-Site, Origin, and Referer are all absent (incomplete fix for GHSA-6m52-m754-pw2g)
Full technical description
This is an incomplete fix for GHSA-6m52-m754-pw2g. Source code may still 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-6m52-m754-pw2g added an Origin / Referer fallback to the dev-middleware same-origin check, with a return true branch when neither header is present so that non-browser clients (curl, the HMR client, address-bar navigation) keep working.
That fallback is bypassed when a cross-origin attacker request reaches the dev server with all three signal headers absent:
Sec-Fetch-Siteis not sent by browsers to non-potentially-trustworthy destinations (HTTP on a non-loopback address).Originis not sent on non-CORS subresource fetches (a bare<script>with nocrossorigin).Referercan be suppressed by the attacker page with<meta name="referrer" content="no-referrer">orreferrerpolicy="no-referrer"on the<script>element.
A classic <script src="http://VICTIM_LAN_IP:3000/_nuxt/app.js" referrerpolicy="no-referrer"> from a non-trustworthy attacker origin produces exactly that header set, the request is allowed, and the attacker page can read the built source out of window.webpackChunk* via Function.prototype.toString().
Since the attack requires the dev server to be reachable via a non-potentially-trustworthy origin, only apps using --host (or --host 0.0.0.0) are affected. Chrome 142+ users are also protected by Local Network Access restrictions.
PoC
- Create a Nuxt project with the webpack / rspack builder.
- Run
npm run dev -- --host 0.0.0.0. - Open
http://localhost:3000on the developer machine. - From a different LAN host, serve the page below and open it in the same browser.
- The compiled module source is exfiltrable from
window.webpackChunknuxt_<projectname>.
<!doctype html>
<meta name="referrer" content="no-referrer">
<script>
['/_nuxt/runtime.js', '/_nuxt/app.js'].forEach(p => {
const s = document.createElement('script')
s.src = 'http://VICTIM_LAN_IP:3000' + p
s.referrerPolicy = 'no-referrer'
document.head.appendChild(s)
})
setTimeout(() => {
const key = Object.keys(window).find(k => k.startsWith('webpackChunk'))
for (const [, mods] of window[key]) {
for (const id in mods) {
console.log(id, mods[id].toString())
}
}
}, 1500)
</script>
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.
Credit
Reported by Berkan SAL (@Uhudsavasindankacanokcu2) via the Vercel Open Source HackerOne program.
Independently reported by @DavidCarliez via GitHub's coordinated disclosure flow (GHSA-xw96-2f5x-v9pv), closed as a duplicate of this advisory.
Impact
Users using the webpack / rspack builder with nuxt dev --host may get the built source code read by malicious websites on the same network, including module identifiers, the developer's local filesystem path, and any developer-controlled strings inlined into the bundle.
This vulnerability does not affect Chrome 142+ (and other Chromium-based browsers) users due to Local Network Access restrictions.
The default Vite builder is not affected.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in @nuxt/[email protected] / @nuxt/[email protected] and backported to @nuxt/[email protected] / @nuxt/[email protected] by #35200 (4.x: commit e351de94; 3.x: commit 77187ee4). The dev-middleware same-origin check now treats a request with no Sec-Fetch-Site, no Origin, and no Referer as same-origin only when the dev server is loopback-bound, closing the header-suppression bypass.
The fix only ships for the @nuxt/webpack-builder and @nuxt/rspack-builder packages. The default Vite builder was not affected.
Frequently Asked Questions
- What is CVE-2026-49993? CVE-2026-49993 is a medium-severity security vulnerability in @nuxt/webpack-builder (npm), affecting versions >= 4.0.0, < 4.4.7. It is fixed in 4.4.7, 3.21.7.
- Which packages are affected by CVE-2026-49993?
@nuxt/webpack-builder(npm) (versions >= 4.0.0, < 4.4.7)@nuxt/rspack-builder(npm) (versions >= 4.0.0, < 4.4.7)
- Is there a fix for CVE-2026-49993? Yes. CVE-2026-49993 is fixed in 4.4.7, 3.21.7. Upgrade to this version or later.
- Is CVE-2026-49993 exploitable, and should I be worried? Whether CVE-2026-49993 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-49993 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-49993?
- Upgrade
@nuxt/webpack-builderto 4.4.7 or later - Upgrade
@nuxt/webpack-builderto 3.21.7 or later - Upgrade
@nuxt/rspack-builderto 4.4.7 or later - Upgrade
@nuxt/rspack-builderto 3.21.7 or later
- Upgrade