CVE-2026-45670: Nuxt Dev Server Source Code Exposure via Incomplete Security Fix

Technical summary

The vulnerability stems from inadequate isolation of the Nuxt development server when exposed to network-accessible addresses. Both @nuxt/rspack-builder and @nuxt/webpack-builder fail to properly restrict source code access in certain configurations. The attack scenario requires two conditions: (1) the dev server must be bound to a non-loopback address (0.0.0.0, a specific IP, or similar), and (2) the developer must visit a malicious website under attacker control while the dev server is running. Under these conditions, the attacker's site can make requests to the accessible dev server and retrieve source code artifacts. This represents an incomplete remediation of GHSA-4gf7-ff8x-hq99, indicating that the original fix did not fully address the underlying exposure vector. The attack requires user interaction (visiting a malicious site) and network adjacency, which limits but does not eliminate the practical risk.

Business impact

For development teams using Nuxt, this vulnerability primarily affects developer productivity and confidentiality of proprietary source code. If source code is exposed, competitors or malicious actors could gain insight into implementation details, business logic, authentication mechanisms, API structures, and other intellectual property. The risk is elevated in environments where developers work on open networks (corporate WiFi, coffee shops, shared office spaces) or where the dev server is intentionally exposed for team collaboration. The vulnerability does not directly impact production systems, as it only affects the development build server. However, stolen source code could be analyzed for additional vulnerabilities or used in targeted supply-chain attacks. Organizations relying on Nuxt should prioritize updating to patched versions to prevent source exposure during the development lifecycle.

Affected systems

The vulnerability affects users of @nuxt/rspack-builder versions 3.15.4 through 3.21.5 and @nuxt/webpack-builder versions 3.15.4 through 3.21.5, as well as @nuxt/rspack-builder and @nuxt/webpack-builder versions 4.0.0-alpha.1 through 4.4.5. Any developer using these versions who runs 'nuxt dev' with a --host flag (or equivalent non-loopback binding) is exposed. The risk increases in environments where developers routinely use networked development setups or where the dev server is intentionally shared across a team. Organizations should inventory Nuxt projects and verify the installed versions of both builder packages.

Exploitability

Exploitation requires moderate complexity and user interaction. An attacker must (1) have network access to the same network segment as the developer, (2) craft a malicious website, (3) socially engineer or otherwise trick the developer into visiting that site while the dev server is running, and (4) the dev server must be exposed to a non-loopback address. The CVSS score of 5.4 (MEDIUM) reflects these constraints. This is not a worm-like or self-propagating vulnerability; it requires deliberate attacker action and developer cooperation. The attack is not remotely exploitable from the internet unless the dev server is intentionally exposed via port forwarding or similar mechanisms. Given these friction points, opportunistic exploitation is unlikely, but targeted attacks against specific developers (e.g., as part of a supply-chain or corporate espionage campaign) are plausible.

Remediation

Update @nuxt/rspack-builder and @nuxt/webpack-builder to version 3.21.6 or later (for the v3 line) and version 4.4.6 or later (for the v4 line). Verify the package versions in your package.json or lock file, then run 'npm update' or 'yarn upgrade' as appropriate. After updating, restart any running dev servers. As an interim mitigation, avoid exposing the dev server to non-loopback addresses in untrusted network environments; use 'nuxt dev' without the --host flag or bind to 127.0.0.1 only. For team collaboration, consider using VPN, SSH tunneling, or other authenticated channels rather than exposing the dev server directly to the network.

Patch guidance

Verify your current Nuxt version by checking package.json and running 'npm list @nuxt/rspack-builder @nuxt/webpack-builder' (or yarn equivalent). If you are on version 3.15.4 or later but before 3.21.6, or on 4.0.0-alpha.1 or later but before 4.4.6, update immediately. The patch addresses the incomplete remediation of the earlier GHSA-4gf7-ff8x-hq99 issue. Test the patched version in your development environment to ensure no regressions before widespread rollout. No breaking changes are expected from these patch releases.

Detection guidance

Monitor dev server logs for unexpected requests to source code assets (JavaScript, CSS, and other bundle files) from external IP addresses. Implement network segmentation to restrict dev server access to designated developer machines only. Use firewall rules to block inbound connections to dev server ports (typically 3000 and upward) from non-local sources. Consider deploying development environment monitoring that alerts when a dev server is bound to 0.0.0.0 or public IP addresses. Code review practices should include verification that dev server configuration in CI/CD pipelines and documentation does not encourage insecure bindings.

Why prioritize this

While rated MEDIUM severity, this vulnerability warrants prioritization because it directly threatens source code confidentiality—a critical asset for software companies. The incomplete fix status suggests that the development team may not have fully understood the original attack vector, raising concerns about lingering gaps. Development-phase vulnerabilities are often overlooked in favor of runtime issues, but compromised source code can have cascading effects on the entire product roadmap. Any organization using Nuxt should treat this as high-priority for development teams, even if it does not affect production systems directly.

Risk score, explained

The CVSS 3.1 score of 5.4 (MEDIUM, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N) reflects network accessibility, low attack complexity, and lack of privilege requirements, but is tempered by the requirement for user interaction (visiting a malicious site) and unchanged scope. The integrity impact (I:L) acknowledges that source code modifications could theoretically occur, though the primary impact is confidentiality (C:L). No availability impact is scored. The rating does not account for context-specific factors such as the criticality of source code assets or supply-chain implications; organizations should consider their own risk tolerance and adjust prioritization accordingly.

Frequently asked questions