CVE-2026-27977

What it actually does

In affected Next.js development servers, the cross-origin authorization logic protecting internal development websocket endpoints can incorrectly treat an HTTP `Origin: null` header as a bypass condition. When `next dev` is reachable from attacker-controlled content, a sandboxed or otherwise opaque-origin document can initiate a websocket connection to the Hot Module Replacement endpoint, such as `/_next/webpack-hmr`, even when `allowedDevOrigins` is configured to restrict access. This can expose or allow interaction with development websocket traffic. The flaw affects development mode only and does not apply to production Next.js builds served with `next start` or a production hosting platform configuration.

Why it matters to the business

The primary risk is exposure of development-only application behavior, code-change metadata, error details, and live reload traffic if developers or teams expose `next dev` beyond trusted local networks. This can lead to leakage of sensitive development information, unintended interaction with a developer workflow, and possible compromise of pre-production workstations or environments depending on what the dev server exposes. The issue is not known to be exploited in the wild, is not in the CISA KEV catalog, has low EPSS, and is not associated with ransomware campaigns, but it should still be remediated anywhere development servers are reachable from browsers or untrusted networks.

How an attack unfolds

An attacker first needs a reachable Next.js development server running an affected version and exposed to a network where attacker-controlled browser content can attempt connections. The attacker then induces a user or browser context to load attacker-controlled content, such as a sandboxed document that produces an opaque origin and sends `Origin: null`. From that content, the attacker opens a websocket connection to the development server's internal HMR endpoint, commonly `/_next/webpack-hmr`. Because the affected authorization logic can fail to apply the configured `allowedDevOrigins` policy to `Origin: null`, the connection may be accepted. Once connected, the attacker can observe or interact with development websocket traffic that was intended only for trusted development origins.

How to fix it

Upgrade Next.js to version 16.1.7 or later, where `Origin: null` is validated using the same origin-allowance logic as other origins. If immediate upgrade is not possible, do not expose `next dev` to untrusted networks; bind development servers to localhost where feasible; place development servers behind trusted network controls; and block websocket upgrade requests to `/_next/webpack-hmr` when the request contains `Origin: null`. Do not rely on `allowedDevOrigins` alone for exposed affected versions. Ensure production deployments use production build/runtime paths rather than `next dev`.

How to confirm the fix worked

Confirm package versions show Next.js 16.1.7 or later for any project using the 16.x development server. Validate that no internet- or untrusted-network-facing service is running `next dev`. Test the mitigation by sending a websocket upgrade request to `/_next/webpack-hmr` with `Origin: null`; patched or mitigated systems should reject the connection unless explicitly allowed by the corrected policy. Review reverse proxy and edge rules to confirm they deny websocket upgrades to the HMR path when `Origin` is `null`. Confirm production services are not exposing development-only endpoints or logs indicating a Next.js development server.

Typical attack path

1. Identify a Next.js development server exposed over a reachable network.
2. Confirm the server is running in development mode and exposes the HMR websocket endpoint, commonly `/_next/webpack-hmr`.
3. Host or deliver attacker-controlled browser content capable of creating an opaque-origin request that sends `Origin: null`, such as a sandboxed document.
4. Cause a user/browser context with network access to the dev server to load the attacker-controlled content.
5. Initiate a websocket upgrade request to the development server's HMR endpoint with `Origin: null`.
6. If the server is affected, establish the websocket connection despite configured development origin restrictions.
7. Observe or interact with development websocket traffic intended for trusted development clients.

How to detect it

Review web server, reverse proxy, load balancer, and application access logs for websocket upgrade requests to Next.js development endpoints, especially `/_next/webpack-hmr`, where the request contains `Origin: null`. Prioritize events from untrusted IP addresses, unexpected referrers, browser user agents, or requests occurring outside normal developer activity. Look for HTTP 101 Switching Protocols responses to the HMR endpoint with `Origin: null`, which indicate a successful websocket upgrade. Also review process, container, and deployment telemetry for exposed `next dev` processes, development server banners, or services listening on non-localhost interfaces. If available, inspect network telemetry for websocket traffic to `/_next/webpack-hmr` from unusual clients. There are no public threat actors or campaigns currently associated with this vulnerability, so detection should focus on endpoint exposure and suspicious HMR websocket access patterns rather than named actor tooling.

• /_next/webpack-hmr
• Origin: null
• Upgrade: websocket
• Connection: Upgrade
• 101 Switching Protocols
• GET /_next/webpack-hmr
• next dev
• next-server
• allowedDevOrigins

What your security team should do

• Inventory repositories, containers, developer workstations, CI preview systems, and pre-production environments for Next.js versions 16.0.1 through 16.1.6 running in development mode.
• Upgrade affected projects to Next.js 16.1.7 or later as the preferred fix.
• Immediately restrict `next dev` to localhost or trusted networks; do not expose development servers directly to the internet.
• Add proxy or WAF controls to block websocket upgrade requests to `/_next/webpack-hmr` when `Origin: null` is present.
• Search historical access logs for websocket upgrade attempts to `/_next/webpack-hmr` with `Origin: null`.
• Confirm production deployments are built and served in production mode, not using `next dev`.
• Educate development teams that `allowedDevOrigins` is not a substitute for network isolation on affected versions.