CVE-2026-27889: 
NixOS vulnerability analysis and mitigation

CVE-2026-27889 is a pre-authentication remote denial-of-service vulnerability in NATS Server (nats-server) caused by a WebSocket frame length integer overflow in the wsRead function. An unauthenticated attacker with TCP access to the WebSocket port can crash the entire server process by sending a single crafted 15-byte WebSocket frame. Affected versions are nats-server v2.2.0 through v2.11.12 and v2.12.0 through v2.12.4; patched versions are v2.11.14 and v2.12.5. The vulnerability was reported by GitHub user @Mistz1 and independently by @jiayuqi7813, published on March 24, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, NATS Advisory).

The root cause is an integer overflow/wraparound (CWE-190) combined with improper input validation (CWE-1286) in server/websocket.go at line 278. When a WebSocket frame uses the 64-bit extended payload length (length code 127), the server reads 8 bytes and casts the raw uint64 directly to int without validating that the most significant bit (MSB) is zero, as required by RFC 6455 §5.2. An attacker sends a frame with the MSB set in the 64-bit length field (e.g., 0x8000000000000001), causing int(0x8000000000000001) to produce -9223372036854775807 via two's complement reinterpretation. This negative value bypasses the bounds clamp at lines 307–311 (since pos + n wraps to a negative value, never exceeding max), and the subsequent slice expression buf[pos : pos+n] triggers a Go runtime panic. Because no defer recover() exists in the goroutine chain (startGoRoutine → readLoop → wsRead), the unrecovered panic propagates to Go's runtime, which calls os.Exit(2), terminating the entire server process. This parsing occurs immediately after the HTTP upgrade handshake, before any NATS CONNECT authentication (GitHub Advisory).

Successful exploitation results in a complete crash of the nats-server process, causing a full availability outage with no confidentiality or integrity impact. All connected clients — including NATS, WebSocket, MQTT, cluster routes, gateways, and leaf nodes — are immediately disconnected upon crash. In clustered deployments, JetStream in-flight acknowledgments are lost and Raft consensus is disrupted. The attack is repeatable on every server restart, enabling a persistent denial-of-service condition against any deployment with WebSocket listeners exposed to untrusted networks, including IoT and browser-based client environments (GitHub Advisory, NATS Advisory).

A public proof-of-concept exploit (Go implementation) was included in the original security advisory by @Mistz1, and an independent Python exploit was provided by @jiayuqi7813 prior to publication — both are publicly available (GitHub Advisory). No credentials, TLS client certificate, or valid NATS client are required; only TCP access to the WebSocket port is needed. The EPSS score is approximately 0.094% (26th percentile), indicating a currently low but non-trivial probability of exploitation in the wild. No in-the-wild exploitation or threat actor attribution has been reported, and the vulnerability is not currently listed in the CISA KEV catalog (GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible nats-server instances with WebSocket listeners enabled (default port 9222 or as configured) using tools like Shodan, Censys, or nmap, targeting versions v2.2.0–v2.11.12 or v2.12.0–v2.12.4.
2. Establish TCP connection: Open a raw TCP connection to the target's WebSocket port.
3. Perform WebSocket upgrade: Send a valid HTTP GET request with WebSocket upgrade headers (Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key, Sec-WebSocket-Version: 13, Sec-WebSocket-Protocol: nats) and confirm a 101 Switching Protocols response.
4. Craft malicious frame: Construct a 15-byte WebSocket frame: byte 0 = 0x82 (FIN + Binary opcode), byte 1 = 0xFF (MASK bit + length code 127), bytes 2–9 = 0x8000000000000001 (64-bit length with MSB set), bytes 10–13 = mask key (e.g., 0xDEADBEEF), byte 14 = one masked payload byte (e.g., 0x41).
5. Send the frame: Transmit the 15-byte frame over the established WebSocket connection. The server's wsRead() function casts the malformed length to a negative int, bypasses the bounds clamp, and triggers a Go runtime panic.
6. Confirm crash: Attempt a new TCP connection to the WebSocket port; a connection failure confirms the server process has terminated with os.Exit(2). The attack can be repeated after each server restart (GitHub Advisory).

• Logs: nats-server process logs showing panic: runtime error: slice bounds out of range [:-9223372036854775793] followed by a goroutine stack trace referencing server/websocket.go:311, server/client.go:1434, and server/server.go:4078; abrupt process exit with code 2 (os.Exit(2)).
• Network: Single short-lived TCP connection to the WebSocket port (default 9222) that completes an HTTP 101 upgrade and immediately sends ~15 bytes before the connection drops; no subsequent NATS CONNECT message from the same source.
• Process: Unexpected termination of the nats-server process without a graceful shutdown signal; all client connections dropping simultaneously with no prior error messages.
• System: Automated process restart logs (e.g., systemd nats-server.service restart entries) occurring repeatedly in short succession, indicating a persistent DoS loop (GitHub Advisory).

Upgrade nats-server to v2.11.14 or v2.12.5, which contain the fix for this vulnerability (GitHub Advisory, NATS Advisory). As a workaround for deployments that cannot immediately upgrade, restrict network access to the WebSocket port to trusted endpoints only (e.g., via firewall rules or network segmentation), or disable the WebSocket listener (websocket { ... } block) in the nats-server configuration if it is not required. Deployments that do not use WebSocket listeners are not affected by this vulnerability.

The vulnerability was disclosed via the official NATS security advisory and GitHub Security Advisory on March 24–25, 2026, with Red Hat tracking it via Bugzilla as a high-severity issue (Red Hat Bugzilla). OpenSUSE issued a security announcement for affected packages, and GitLab's advisory database also catalogued the vulnerability (OpenSUSE Announce). Community discussion was noted on Bluesky and security aggregator platforms, reflecting moderate attention given the straightforward exploitability and the public PoC included in the advisory itself.