CVE-2026-27977
Vercel Next.Js 16.0.1 – 16.1.7
Raw vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-27977 is a low-severity Missing Origin Validation in WebSockets (CWE-1385) vulnerability in Vercel Next.Js. Its CVSS base score is 2.3 (Low).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 7th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-3 (Access Enforcement) and SC-7 (Boundary Protection) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-12683
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
Vulnerability enables unauthorized websocket connections to a publicly reachable dev server via origin validation bypass, directly facilitating exploitation of a public-facing web application.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly enforces origin-based access decisions on the HMR websocket endpoint, rejecting unauthorized Origin values including null.
Boundary protection at a proxy or WAF can explicitly drop websocket upgrades to /_next/webpack-hmr when Origin is null or unallowed.
Requires validation of the Origin header value against the allowedDevOrigins policy before permitting the connection.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require origin validation for WebSocket endpoints.
Origin validation is a required step when authenticating WebSocket connection requests.
Enforcing authorization policy on incoming connections can require origin checks.
Network-level controls that block unauthorized logical access can mitigate missing origin checks.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect missing origin validation in WebSocket implementations.
Network security controls can enforce origin validation and restrict WebSocket connections to trusted sources.
Secure configuration of network services can include origin checks for WebSocket endpoints.
Application security requirements can mandate origin validation for WebSocket communications.
Secure architecture principles can require proper origin validation mechanisms in WebSocket implementations.
Secure coding standards can explicitly require origin validation for WebSocket connections.