CVE-2026-27977 Overview
CVE-2026-27977 is an Origin Bypass vulnerability affecting Next.js, a popular React framework for building full-stack web applications. The vulnerability exists in the development mode (next dev) where cross-site protection for internal websocket endpoints incorrectly treats Origin: null as a bypass case, even when allowedDevOrigins is configured. This allows privacy-sensitive or opaque contexts, such as sandboxed documents, to establish unexpected connections to the Hot Module Replacement (HMR) websocket channel.
Critical Impact
Attackers with access to controlled content that can reach a vulnerable development server may connect to the HMR websocket channel and interact with development websocket traffic, potentially exposing sensitive development data or enabling unauthorized interactions.
Affected Products
- Vercel Next.js versions 16.0.1 through 16.1.6 (prior to 16.1.7)
Discovery Timeline
- 2026-03-18 - CVE CVE-2026-27977 published to NVD
- 2026-03-18 - Last updated in NVD database
Technical Details for CVE-2026-27977
Vulnerability Analysis
This vulnerability involves an authorization bypass in the cross-site origin validation logic of Next.js development mode. When a websocket connection request arrives at the /_next/webpack-hmr endpoint with an Origin: null header, the server fails to properly validate this origin against the configured allowedDevOrigins list. The Origin: null value is commonly sent by browsers for requests originating from privacy-sensitive contexts such as sandboxed iframes, local file:// URLs, or cross-origin redirects.
The flaw allows an attacker who can serve malicious content that reaches the development server to bypass the intended origin restrictions and establish a websocket connection to the HMR channel. This could enable the attacker to observe real-time code changes, inject malicious payloads into the development workflow, or gather information about the application being developed.
Root Cause
The root cause lies in the blockCrossSite function within the router server logic. The original implementation did not properly validate Origin: null headers through the same cross-site origin-allowance checks applied to other origin values. When the origin header was null, the validation logic treated it as a special bypass case rather than subjecting it to the configured allowlist restrictions.
Attack Vector
The attack requires network access to the vulnerable Next.js development server. An attacker must be able to serve content (such as a malicious webpage or sandboxed document) that can initiate websocket connections to the target development server. The attack exploits the permissive handling of Origin: null headers by:
- Serving content from a privacy-sensitive context (e.g., sandboxed iframe) that sends Origin: null
- Initiating a websocket connection to /_next/webpack-hmr on the target development server
- Establishing an unauthorized connection to the HMR channel despite allowedDevOrigins configuration
The following patch demonstrates the security fix applied by Vercel:
import { NEXT_PATCH_SYMBOL } from './patch-fetch'
import type { ServerInitResult } from './render-server'
import { filterInternalHeaders } from './server-ipc/utils'
-import { blockCrossSite } from './router-utils/block-cross-site'
+import { blockCrossSiteDEV } from './router-utils/block-cross-site-dev'
import { traceGlobals } from '../../trace/shared'
import { NoFallbackError } from '../../shared/lib/no-fallback-error.external'
import {
Source: GitHub Commit Changes
return true
}
-function isInternalDevEndpoint(req: IncomingMessage): boolean {
+function isInternalEndpoint(req: IncomingMessage): boolean {
if (!req.url) return false
try {
Source: GitHub Commit Changes
Detection Methods for CVE-2026-27977
Indicators of Compromise
- Unexpected websocket connections to /_next/webpack-hmr endpoints from unknown or null origins
- Network logs showing HMR websocket connections originating from sandboxed iframes or privacy-sensitive contexts
- Development server logs indicating websocket upgrade requests with Origin: null headers
Detection Strategies
- Monitor development server access logs for websocket upgrade requests to /_next/webpack-hmr with suspicious or null origin headers
- Implement network-level monitoring to detect unexpected external connections to development server ports
- Review proxy logs for websocket connections that bypass expected origin restrictions
Monitoring Recommendations
- Configure network firewalls to alert on external connections to development server ports
- Implement logging for all websocket connections to HMR endpoints including origin header values
- Use development environment isolation to prevent exposure of dev servers to untrusted networks
How to Mitigate CVE-2026-27977
Immediate Actions Required
- Upgrade Next.js to version 16.1.7 or later immediately
- Ensure development servers are not exposed to untrusted networks
- Review network configurations to restrict access to development environments
- If using a reverse proxy, configure it to block websocket upgrades to /_next/webpack-hmr when the Origin header is null
Patch Information
Vercel has addressed this vulnerability in Next.js version 16.1.7. The fix ensures that Origin: null headers are validated through the same cross-site origin-allowance checks used for other origins. The patch modifies the internal origin validation functions to properly handle null origin cases.
For detailed patch information, see the GitHub Security Advisory GHSA-jcc7-9wpm-mj36 and the GitHub Release v16.1.7.
Workarounds
- Do not expose next dev to untrusted networks or the public internet
- Block websocket upgrades to /_next/webpack-hmr at the proxy level when the Origin header is null
- Use network segmentation to isolate development environments from potentially malicious content sources
# Example nginx configuration to block null origin websocket upgrades
location /_next/webpack-hmr {
# Block requests with null Origin header
if ($http_origin = "null") {
return 403;
}
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


