CVE-2026-27977 in next.js
Summary
by MITRE • 03/18/2026
Next.js is a React framework for building full-stack web applications. Starting in version 16.0.1 and prior to version 16.1.7, in `next dev`, cross-site protection for internal websocket endpoints could treat `Origin: null` as a bypass case even if `allowedDevOrigins` is configured, allowing privacy-sensitive/opaque contexts (for example sandboxed documents) to connect unexpectedly. If a dev server is reachable from attacker-controlled content, an attacker may be able to connect to the HMR websocket channel and interact with dev websocket traffic. This affects development mode only. Apps without a configured `allowedDevOrigins` still allow connections from any origin. The issue is fixed in version 16.1.7 by validating `Origin: null` through the same cross-site origin-allowance checks used for other origins. If upgrading is not immediately possible, do not expose `next dev` to untrusted networks and/or block websocket upgrades to `/_next/webpack-hmr` when `Origin` is `null` at the proxy.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 03/23/2026
This vulnerability affects Next.js development servers running versions 16.0.1 through 16.1.6, specifically within the `next dev` command functionality. The issue stems from improper validation of websocket connection origins during development mode operations, creating a security loophole that could allow unauthorized access to internal websocket endpoints. The flaw specifically targets the cross-site protection mechanisms that should prevent unauthorized connections to the Hot Module Replacement (HMR) websocket channel, which is used for live updates during development. When the `Origin: null` header is present in websocket upgrade requests, the system incorrectly treats this as a valid bypass case even when administrators have explicitly configured `allowedDevOrigins` to restrict connections. This behavior creates a significant privacy risk as it allows connections from opaque contexts such as sandboxed documents or other privacy-sensitive environments that should normally be restricted from accessing development resources.
The technical implementation of this vulnerability involves the websocket upgrade process where Next.js checks the Origin header to determine whether to allow connections to the internal HMR websocket endpoint at `/_next/webpack-hmr`. In the affected versions, the system fails to properly validate `Origin: null` against the configured `allowedDevOrigins` policy, effectively allowing any connection that presents this specific origin header regardless of the configured security restrictions. This validation bypass occurs exclusively in development mode and does not affect production deployments, but it creates a dangerous situation where attacker-controlled content could potentially establish websocket connections to the development server's internal channels. The vulnerability is particularly concerning because it allows connections from contexts that are typically isolated for security reasons, such as sandboxed documents or other privacy-sensitive environments that should be prevented from accessing development resources.
The operational impact of this vulnerability is significant for development environments that are exposed to untrusted networks or content. When a development server is accessible from attacker-controlled websites or content, an attacker could potentially establish websocket connections to the HMR channel and interact with development websocket traffic. This could enable various malicious activities including but not limited to monitoring development processes, potentially gaining information about internal application structures, or even exploiting other development-time vulnerabilities that may exist. The vulnerability essentially undermines the security boundaries that should exist between development environments and untrusted network contexts. Since this affects only development mode and not production deployments, organizations using Next.js in production are not directly impacted by this specific vulnerability, but the development servers themselves remain at risk when exposed to untrusted networks. The risk is particularly elevated in environments where development servers are publicly accessible or deployed in shared hosting environments where multiple parties might have access to the network infrastructure.
The fix implemented in Next.js version 16.1.7 addresses this vulnerability by ensuring that `Origin: null` is validated through the same cross-site origin-allowance checks that are applied to all other origins, rather than treating it as a special bypass case. This change brings the validation logic for `Origin: null` in line with the standard cross-site protection mechanisms, ensuring that configured `allowedDevOrigins` policies are properly enforced even when the origin header is null. Organizations that cannot immediately upgrade to version 16.1.7 or later should implement network-level mitigations such as blocking websocket upgrades to the `/_next/webpack-hmr` endpoint when the `Origin` header is `null`, or ensuring that development servers are not exposed to untrusted networks through proper network segmentation and access controls. The vulnerability aligns with CWE-346 (Origin Validation) and can be categorized under ATT&CK technique T1071.004 (Application Layer Protocol: DNS) and T1046 (Network Service Scanning) when exploited in conjunction with other reconnaissance activities, though the primary concern remains the improper handling of websocket origin validation in development environments.
This vulnerability demonstrates the importance of proper origin validation even in development contexts where security boundaries might be perceived as less critical. The issue highlights how development server configurations can create unexpected attack vectors when security controls are not consistently applied across all connection types and headers. Organizations should implement robust network segmentation practices to ensure that development servers are not accessible from untrusted networks, and should regularly review their development environment configurations to prevent exposure to potential attackers. The fix represents a good example of how security controls should be consistently applied across all connection types, ensuring that special cases like `Origin: null` do not inadvertently create security bypasses that could be exploited by attackers.