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.

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, 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, 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.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.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.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, a cloud and edge native messaging system. Prior to versions 2.11.15 and 2.12.6, 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. Versions 2.11.15 and 2.12.6 contain a fix. No known workarounds are available.

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>

Missing access controls for JS API in multi-tenancy

NATS-advisory-ID: 2025-01 Aliases: CVE-2025-30215, GHSA-fhg8-qxh5-7q3w Date: 2025-04-08 Fixed-In: nats-server 2.11.1, 2.10.27

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 account system provides for multi-tenancy and isolation. JetStream provides for persistent storage of messages and at-least-once guarantees.

Problem Description:

The management of JetStream assets happens with messages in the $JS. subject namespace in the system account; this is partially exposed into regular accounts to allow account holders to manage their assets.

Some of the JS API requests were missing access controls, allowing any user with JS management permissions in any account to perform certain administrative actions on any JS asset in any other account. At least one of the unprotected APIs allows for data destruction. None of the affected APIs allow disclosing stream contents.

Affected versions:

NATS Server: Version 2 from v2.2.0 onwards, prior to v2.11.1 or v2.10.27

Workarounds:

None

Solution:

Upgrade the NATS server to a fixed version.

Credits:

This problem was reported by Thomas Morgan on 2025-03-05.

Timeline Note:

The GHSA is currently (2024-04-08) still draft, and we intend to publish it one week from today, with the original reporter's full details on how they verified the bug.

References:

This document is canonically: <https://advisories.nats.io/CVE/secnote-2025-01.txt> GHSA advisory (pending): <https://github.com/nats-io/nats-server/security/advisories/GHSA-fhg8-qxh5-7q3w> MITRE CVE entry: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-30215>

NATS-advisory-ID: 2023-02 Aliases: CVE-2023-46129, GHSA-mr45-rx8q-wcm9 Date: 2023-10-26 Fixed-In: nkeys 0.4.6; nats-server 2.10.4

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. All usage of nkeys prior to the January 2023 0.4.0 release was signing-only.

Within the nats-server, the encryption is used for the Auth Callouts feature, introduced with 2.10.0 (September 2023). The Auth Callout request includes the supplied user password. These messages are sent within NATS, and should typically be in a dedicated NATS Account used for callouts, but this is not required. Thus in scenarios where the Callouts are in an account shared with untrusted users or where the callout responders connect without TLS, this may lead to user credential exposure.

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

Workarounds:

None available.

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).

References:

GitHub Security Advisory for nkeys & nats-server: <https://github.com/nats-io/nkeys/security/advisories/GHSA-mr45-rx8q-wcm9>

On 2023-10-29 at 15:51 -0400, Phil Pennock wrote: On 2023-10-28 at 17:51 +0200, Salvatore Bonaccorso wrote: On Thu, Oct 12, 2023 at 10:39:53PM -0400, Phil Pennock wrote: [ CVE has been requested, still waiting for assignment, so we're just inventing our own in-house numbering for advisories; we'll make sure this one continues to work after the CVE is issued ]

NATS-advisory-ID: 2023-01 CVE: pending Date: 2023-10-12 Fixed in: 2.9.23, 2.10.2 While I see the later NATS-advisory-ID 2023-02 has a CVE assigned, for the 2023-01 was above with CVE pending. has one been assigned in meanwhile? No. Now: yes. CVE-2023-47090 has been assigned today.

My thanks to whomever gave the nudge.

(Website will be updated as soon as GitHub has an action runner available to process the pages build).

-Phil

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).

On 2023-10-28 at 17:51 +0200, Salvatore Bonaccorso wrote: On Thu, Oct 12, 2023 at 10:39:53PM -0400, Phil Pennock wrote: [ CVE has been requested, still waiting for assignment, so we're just inventing our own in-house numbering for advisories; we'll make sure this one continues to work after the CVE is issued ]

NATS-advisory-ID: 2023-01 CVE: pending Date: 2023-10-12 Fixed in: 2.9.23, 2.10.2 While I see the later NATS-advisory-ID 2023-02 has a CVE assigned, for the 2023-01 was above with CVE pending. has one been assigned in meanwhile? No.

For 2023-01 I went with our existing procedure and requested an assignment from MITRE, just as in all prior cases. I got the automated acknowledgement (on Thursday 28th Sep, request ID 1532633). I've yet to get a CVE assignment.

So for the next one, I tried a new approach. I filled out the GitHub Security Advisory flow ahead of release, got a GHSA, and requested a CVE immediately. It looks like that was issued the next day.

Going forward, the NATS project will be using GitHub's processes for requesting a CVE assignment. Our documented procedures have been updated.

I'm adjusting our published text format to have known aliases near the top, to make it easier to cross-reference. For NATS advisory 2023-01, this is aka GHSA-fr2g-9hjm-wr23 and GO-2023-2133.

-Phil

Hi,

On Thu, Oct 12, 2023 at 10:39:53PM -0400, Phil Pennock wrote: [ CVE has been requested, still waiting for assignment, so we're just inventing our own in-house numbering for advisories; we'll make sure this one continues to work after the CVE is issued ]

NATS-advisory-ID: 2023-01 CVE: pending Date: 2023-10-12 Fixed in: 2.9.23, 2.10.2 While I see the later NATS-advisory-ID 2023-02 has a CVE assigned, for the 2023-01 was above with CVE pending. has one been assigned in meanwhile?

Regards, Salvatore

[ CVE has been requested, still waiting for assignment, so we're just inventing our own in-house numbering for advisories; we'll make sure this one continues to work after the CVE is issued ]

NATS-advisory-ID: 2023-01 CVE: pending Date: 2023-10-12 Fixed in: 2.9.23, 2.10.2

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.

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.

(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.

(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.

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.