CVE-2026-27977: 
ASP.NET Core vulnerability analysis and mitigation

CVE-2026-27977 is an origin validation bypass vulnerability in Next.js's development server (HMR WebSocket) that allows privacy-sensitive or opaque browser contexts (e.g., sandboxed documents) to bypass cross-site protections by sending Origin: null. It affects Next.js versions 16.0.1 through 16.1.6 (npm package next) and was disclosed on March 16, 2026, with a patch released the same day. The vulnerability carries a CVSS v3.1 score of 5.4 (Medium) and a CVSS v4.0 score of 2.3 (Low), and is limited to development mode only — production deployments are not affected (GitHub Advisory, Github Advisory).

The root cause is classified as CWE-1385 (Missing Origin Validation in WebSockets) — specifically, the blockCrossSite function in packages/next/src/server/lib/router-utils/block-cross-site.ts explicitly skipped validation when the Origin header value was the string 'null' (i.e., if (rawOrigin && rawOrigin !== 'null')), treating it as a safe case rather than subjecting it to the same allowlist checks applied to other origins (GitHub Commit). Browsers send Origin: null from privacy-sensitive or opaque contexts such as sandboxed iframes or documents loaded via file://, meaning attacker-controlled sandboxed content could initiate a WebSocket connection to the HMR endpoint /_next/webpack-hmr even when allowedDevOrigins was configured to restrict access. Exploitation requires that a developer visit attacker-controlled content while their next dev server is reachable from that context, and that allowedDevOrigins is configured (servers without this setting already allow all origins) (GitHub Advisory).

Successful exploitation allows an attacker to connect to the Next.js HMR WebSocket channel (/_next/webpack-hmr) from a sandboxed or opaque browser context, enabling interception of development WebSocket traffic, potential injection of malicious code into the development environment, and exfiltration of sensitive information transmitted during development. The impact is limited to confidentiality (low) and integrity (low) of the vulnerable system, with no availability impact and no effect on subsequent systems or production deployments (Github Advisory, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Github Advisory). The EPSS score is approximately 0.018% (0th percentile), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires user interaction (a developer visiting attacker-controlled content) and specific deployment conditions (dev server reachable from the attacker's context with allowedDevOrigins configured), further limiting practical exploitability.

1. Setup attacker-controlled content: Host a web page that uses a sandboxed iframe or applies a Content-Security-Policy: sandbox allow-scripts header, causing the browser to assign an opaque origin (null) to the document's context.
2. Embed WebSocket connection attempt: In the sandboxed page's JavaScript, initiate a WebSocket connection to the target developer's Next.js HMR endpoint: new WebSocket('http://<dev-server>/_next/webpack-hmr').
3. Trigger developer visit: Social-engineer the developer into visiting the attacker-controlled page while their next dev server (versions 16.0.1–16.1.6) is running and reachable from the browser.
4. Bypass origin check: The browser sends Origin: null with the WebSocket upgrade request; the vulnerable blockCrossSite function skips validation for this value, allowing the connection to proceed even if allowedDevOrigins is configured.
5. Interact with HMR channel: Once connected, the attacker's sandboxed script can listen to or send messages on the HMR WebSocket, potentially intercepting development traffic or injecting malicious HMR payloads into the developer's build environment (GitHub Advisory, GitHub Commit).

• Network: Unexpected WebSocket upgrade requests to /_next/webpack-hmr with an Origin: null header originating from external or unexpected IP addresses.
• Logs: Dev server access logs showing WebSocket connections to /_next/webpack-hmr where the Origin header is null and the source is not a trusted local or configured origin.
• Process/Behavior: Unusual HMR messages or unexpected module reload events in the Next.js development server console that were not triggered by local file changes.

Upgrade Next.js to version 16.1.7 or later, which fixes the issue by passing Origin: null through the same isCsrfOriginAllowed checks used for all other origins, effectively blocking opaque-origin connections (GitHub Commit, Next.js Release). If immediate upgrade is not possible, apply the following workarounds: (1) Do not expose next dev to untrusted networks — restrict the dev server to localhost or trusted network segments only; (2) At the proxy or firewall level, block WebSocket upgrade requests to /_next/webpack-hmr when the Origin header value is null (GitHub Advisory).

The advisory was published by Vercel maintainer ztanner on March 16, 2026, with credit to security researchers radu33 and xdavidhu for finding the issue (GitHub Advisory). Red Hat tracked the issue via Bugzilla (Bug 2448514) and assigned it medium priority/severity, indicating awareness across the Linux ecosystem (Red Hat Bugzilla). The vulnerability was part of a batch of five CVEs addressed in the Next.js 16.1.7 release, suggesting a coordinated security disclosure effort by the Vercel team (Next.js Release).