GHSA-x6qj-4h56-5rj5
@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)
Blast Radius
@nuxt/webpack-builder📦@nuxt/webpack-builder📦@nuxt/rspack-builder📦@nuxt/rspack-builderReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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>
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.
Patches
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.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @nuxt/webpack-builder | ≥ 4.0.0&&< 4.4.7 | 4.4.7 |
| 📦npm | @nuxt/webpack-builder | ≥ 3.15.4&&< 3.21.7 | 3.21.7 |
| 📦npm | @nuxt/rspack-builder | ≥ 4.0.0&&< 4.4.7 | 4.4.7 |
| 📦npm | @nuxt/rspack-builder | ≥ 3.15.4&&< 3.21.7 | 3.21.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @nuxt/webpack-builder. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @nuxt/webpack-builder to 4.4.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x6qj-4h56-5rj5 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.
How O3 protects you
O3 pinpoints whether GHSA-x6qj-4h56-5rj5 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-x6qj-4h56-5rj5. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-x6qj-4h56-5rj5 in your dependencies?
O3 detects GHSA-x6qj-4h56-5rj5 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.