NATS CVE-2026-27571 WebSocket Compression Bomb Patch and Mitigations

NATS server’s WebSocket handler contains a pre-authentication memory exhaustion vulnerability that can be triggered by a crafted compressed frame — a “compression bomb” — allowing an unauthenticated attacker to force excessive memory allocation and potentially crash the server; the issue is tracked as CVE-2026-27571 and was disclosed via the NATS project’s security advisory and patched in the v2.11 and v2.12 release lines. (github.com)

Background / Overview​

NATS is a lightweight, high-performance messaging server widely used in cloud-native microservices, IoT, and edge deployments. It supports multiple transports, including raw TCP and WebSockets, to meet diverse client requirements. WebSockets are commonly used when browser-based or proxy‑friendly connections are required; however, that convenience brings protocol-level complexity — including negotiated compression extensions like perm-deflate — that must be implemented defensively. (github.com)
CVE-2026-27571 concerns the WebSocket path for NATS messages: the server accepted compressed WebSocket frames and, while it enforced a maximum payload check for final NATS messages, it did not independently limit the memory required during decompression of a compressed frame. An attacker who can reach an exposed WebSocket endpoint can send a highly compressible payload that inflates to a very large uncompressed buffer, causing the server process to allocate far more memory than intended and frequently be terminated by the OS (OOM killer) or to exhaust system resources. Critically, the WebSocket compression negotiation occurs before authentication in the server’s handling path, so a valid NATS credential is not required to start the connection and trigger the issue. (github.com) (github.com)
The vulnerability was cataloged with a CVSS v3.1 base score in the mid-range (availability-impacting) and assigned CVE-2026-27571; the NATS project released fixes in the v2.11 and v2.12 branches — specifically v2.11.12 and v2.12.3 — that restrict the decompression buffer so the server fails early instead of allocating unbounded memory. (github.com) (github.com)

---

What happened (technical summary)​

How WebSocket compression enabled pre-auth DoS​

WebSocket compression (perm-deflate and similar) provides bandwidth savings by allowing a sender to transmit deflated (compressed) payloads that the receiver inflates. Implementations must watch decompressed size carefully: a small compressed payload can expand to a very large decompressed buffer (the classic “compression bomb” problem). In the vulnerable NATS path, the server:

• negotiated WebSocket compression with the client during the handshake (this happens before the server authenticates the NATS client),
• accepted compressed frames and collected frame data into an in-memory buffer,
• deferred the enforcement of the maximum message payload size until after decompression and message assembly.

Because the implementation did not cap the decompressed stream independently, an attacker could send a small compressed frame that expands to many megabytes or gigabytes of memory on decompression — far exceeding the configured or expected message size and consuming system memory. The later size check would reject the message, but only after the expensive decompression and buffer allocation had already occurred. (github.com) (github.com)

What the patch changed​

The fix introduces a hard limit during decompression so that the decompressor stops and returns an error as soon as the uncompressed size would exceed the configured maximum payload (mpay). The commit adds a decompression function that accepts a maximum allowed decompressed size and uses a bounded reader to ensure the server never allocates more than that limit; if the limit would be exceeded the decompress operation returns an ErrMaxPayload (or equivalent), avoiding large allocations. This is a straightforward and robust defensive change that aligns decompression resource use with the existing m-size enforcement policy. (github.com)

---

Why this matters to operators​

• Unauthenticated attack surface: Because the WebSocket compression negotiation occurs before NATS authentication, any unauthenticated remote client that can reach an exposed WebSocket port can trigger the vulnerability. In other words, public-facing WebSocket endpoints are at risk if they accept connections from untrusted networks. (github.com)
• Availability impact: The flaw affects availability only (no confidentiality or integrity impact has been reported), but availability is critical for messaging layers. An attacker can cause server process termination or prolonged unresponsiveness, impacting downstream services and orchestration. The NVD/GitHub advisory lists the primary impact as high on availability.
• Exploit complexity and scope: The advisory describes this as a network vector with high attack complexity (crafting a useful compression bomb is not trivial at scale), but no privileges are required. The vulnerability only affects deployments that enable WebSockets and expose that port to untrusted endpoints. For internal-only WebSocket deployments behind strict network ACLs, the risk is materially lower. (github.com)

---

Timeline and disclosure notes​

• The public GitHub security advisory was published by the NATS project on February 23, 2026, as GHSA-qrvq-68c2-7grw and assigned CVE-2026-27571. The advisory calls out the affected ranges and patched releases. ([github.com](https://github.com/nats-io/nats-server/security/advisories/
• The NVD published an entry for CVE-2026-27571 on February 24, 2026; the NVD summary and CVSS vector provide an independent vendor-agnostic record.
• The underlying fix was included in the server code and in release builds: v2.11.12 (published by the project January 27, 2026) and v2.12.3 (published December 17, 2025). The maintainers note the patch was present in released versions prior to being flagged as a CVE — an oversight the advisory acknowledges and corrects. Operators who have upgraded to those release tags already have the corrective code. (github.com) (github.com)
• The vulnerability was reported by Pavel Kohout of Aisle Research and credited in the advisory and code commit. (github.com)

(As of February 27, 2026 there are no widely reported or authoritative public exploit tools or verified mass-exploitation incidents tied to CVE-2026-27571. I reviewed recent community archive snapshots for early chatter and large-scale exploitation reports and found no confirmed, large-scale exploitation signals in those snapshots. )

---

Detection and triage checklist​

If you run NATS (or manage systems that do), perform the following steps immediately to assess exposure and triage:

• Verify installed versions:
• Run nats-server -v on each node to report the server version.
• If you run packaged images, inspect the image tags (for containers) or package metadata to map to upstream release tags (v2.11.12, v2.12.3 or later are patched). (github.com)
• Identify exposed WebSocket endpoints:
• Inventory network endpoints and check whether NATS WebSockets are bound to 0.0.0.0 or an external-facing VIP.
• Check firewall rules and service definitions for public exposure of WebSocket ports (commonly 4222 with WebSocket support or a separate WebSocket port, depending on config).
• Look for process-level OOMs and crashes:
• On Linux, search journalctl or syslog for OOM killer messages referencing the nats-server process (oom-killer or “Killed process” lines).
• Check container orchestrator events for repeated container restarts or OOM signals.
• Inspect core dumps or panic logs if present.
• Review connection logs and patterns:
• If connection-level logging is enabled, review for unusual WebSocket connection attempts or many small compressed frames from a single source.
• Correlate with upstream network logs and WAF/edge proxies for repeated websocket opens or short-lived sessions that coincide with crashes.
• Apply blocking mitigations:
• If you cannot patch immediately, restrict access to WebSocket endpoints to trusted networks only (network ACLs, security groups). The advisory explicitly lists restricted exposure as a valid workaround. (github.com)

---

Immediate mitigations (practical steps)​

• Upgrade: the single best fix is to upgrade to a patched version.
• Upgrade to nats-server v2.11.12 if you are on the 2.11 line, or to v2.12.3 if you are on the 2.12 line; the patches add bounds to decompression and are included in those releases. Verify the binary/containers you run correspond to those tags. (github.com) (github.com)
• Restrict network exposure:
• Block or restrict the WebSocket port(s) at the perimeter. Limit access to known application IPs or use VPN/zero-trust tunnels for administrative or internal connections.
• Turn off WebSockets where feasible:
• If your deployment does not require browser or proxy-friendly connections, disable WebSockets in the server config until you can patch.
• Apply rate-limiting / WAF rules:
• Deploy an upstream Web Application Firewall or reverse proxy that can impose per‑connection rate and size limits and detect many small compressed frames. While WAFs won't fully prevent a cleverly crafted compression bomb, they can limit the blast radius by rejecting suspicious patterns before the frames reach the NATS process.
• Harden resource limits:
• Run NATS under system-level resource controls (cgroups, systemd ResourceControl) that limit the maximum memory a single process can consume so that a single server cannot exhaust host memory and take down other co-located services.
• Monitor and alert:
• Add alerts for process restarts, OOM messages, and anomalous WebSocket connection patterns so you can rapidly respond to attempts or failures.

---

How to upgrade safely (recommended sequence)​

• Plan a maintenance window for each affected node or cluster member.
• Snapshot or back up persistent JetStream storage and configuration.
• If running in containers, pull the patched image that corresponds to v2.11.12 or v2.12.3 and test in staging.
• Perform a rolling upgrade: drain clients where supported, upgrade one node at a time, verify health and connectivity before proceeding.
• Validate that the server no longer crashes under the same workload and that WebSocket connections behave as expected.

The upstream release notes for v2.11.12 and v2.12.3 explicitly list “WebSocket connections will now correctly limit the buffer size during decompression” as a fixed item; these releases are the authoritative upgrade targets. (github.com) (github.com)

---

Risk analysis and critical appraisal​

Strengths of upstream response​

• The NATS maintainers implemented a targeted, minimal fix that bounds decompression to the configured maximum payload and avoids broad structural changes. The fix is conservative and appropriate for the bug class: the right behavior is to fail fast when decompression would exceed configured limits rather than to perform an unbounded allocation. The change was included in stable release branches (2.11.x and 2.12.x) and credited the reporter, which is good practice. (github.com) (github.com)
• The project published a public advisory and coordinated the CVE, giving operators a clear remediation path and release mapping. The advisory acknowledges that the fix was already present in releases but should have been tracked as a security issue earlier — transparency that helps operator trust. (github.com)

Residual risks and caveats​

• The vulnerability is protocol-surface dependent: only WebSocket-enabled and externally reachable deployments are exposed. However, many cloud deployments intentionally expose WebSocket endpoints for browser clients or IoT devices, so the attack surface can still be large in modern microservice topologies. Operators with internal-only networks still must verify their network boundaries. (github.com)
• The attack requires a crafted compression bomb. While the advisory marks attack complexity as high, that does not mean the risk is negligible: compression bombs are well-known and reproducible; a skilled attacker who can craft or adapt a payload and find an exposed endpoint can execute the attack. The remediation is straightforward, so leaving systems unpatched is an unnecessary operational risk. (github.com)
• Detection is imperfect: because the exploit is pre-auth and the attack pattern may resemble legitimate compressed traffic at a glance, purely application-level logs may not immediately distinguish malicious frames from benign ones. Correlating process-level OOMs, abrupt restarts, and edge-proxy logs provides the best signal. Operators should assume that a lack of logs does not equal lack of attempts.

---

Recommendations for administrators and architects​

• Prioritize patching of any public-facing NATS WebSocket endpoints in the next maintenance window. Use the patched releases referenced above. (github.com)
• Inventory all NATS instances and identify those that:
• have WebSocket enabled, and
• have network exposure to untrusted endpoints (public internet, partner networks, or other untrusted zones).
• Where WebSockets are required, place them behind a hardened proxy that can perform deep inspection, size checks, and per-connection limits; consider terminating WebSocket compression at the proxy if possible and safe, so the application-facing server does not need to decompress untrusted frames.
• Adopt defensive coding and testing practices for similar classes of bugs:
• Add tests that simulate highly compressible payloads to ensure decompression limits are respected.
• Use libraries and reader primitives that allow bounded decompression (e.g., io.LimitedReader patterns) whenever inflating remote data.
• Treat pre-auth protocol negotiation as untrusted input and limit resource consumption accordingly.
• Monitor community advisories and vulnerability databases for follow-ups (new CVE metadata, proof-of-concept exploit releases, or additional affected versions) and ensure your vulnerability management process picks up new NATS advisories promptly. The OSV and NVD entries provide machine-readable and analyst-friendly records for integration into scanners and ticketing.

---

For developers: defensive coding checklist​

• When processing compressed remote input:
• Always decompress into a bounded reader or buffer with a strict maximum size.
• Fail early on decompression size limits with clear errors; do not attempt to continue processing after a decompression overflow.
• Avoid multi-stage validation that only enforces size after expensive transformations; perform resource checks as early as possible.
• When protocol negotiation happens pre-auth:
• Treat negotiation inputs (like compression parameters) as untrusted and bound their consequences (memory, CPU, file descriptors).
• Consider disabling optional features (like compression) by default for services that accept unauthenticated pre-handshake options, or require authentication before enabling them.
• Test with compression-bomb payloads and automated fuzzers that include variations on highly repetitive content to ensure the server fails safely and predictably under attack.

---

Conclusion​

CVE-2026-27571 is a textbook example of a resource-exhaustion flaw that arises from a mismatch between protocol-level processing and resource accounting: WebSocket compression negotiation performed before authentication allowed an attacker to trigger decompression of arbitrarily expansive content, and the server only enforced m-size limits after the expensive decompression step. The fix is straightforward — bound decompression to the configured maximum payload — and NATS has published patched releases in both maintenance branches (v2.11.12 and v2.12.3). Operators should treat this as an urgent but easily remediable availability risk: identify exposed WebSocket endpoints, upgrade to the patched releases, and apply network-level access controls or disable WebSockets until patched. (github.com) (github.com) (github.com) (github.com)
Implement the detection checklist, follow a rolling upgrade plan, and harden your deployment topology so a single pre-auth connection cannot destabilize an entire messaging fabric. As always, verify patches in a staging environment and monitor for post-upgrade regressions; defensive changes that limit resource use are necessary but should be validated against expected workloads.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center