Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
16 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/nats-io/nats-server/v2 < 2.11.15; >= 2.12.0-RC.1, < 2.12.6
Fixed in
2.12.62.11.15· Vendor fix available
Issue
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
Recommended action: Upgrade to 2.12.6 or 2.11.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/nats-io/nats-server/v2 < 2.11.15; >= 2.12.0-RC.1, < 2.12.6
Fixed in
2.12.62.11.15· Vendor fix available
Issue
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…
Recommended action: Upgrade to 2.12.6 or 2.11.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/nats-io/nats-server/v2 >= 2.11.0, < 2.11.15; >= 2.12.0-preview.1, < 2.12.6
Fixed in
2.12.62.11.15· Vendor fix available
Issue
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.
Recommended action: Upgrade to 2.12.6 or 2.11.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/nats-io/nats-server/v2 >= 2.11.0-RC.1, < 2.11.1; >= 2.2.0, < 2.10.27
Fixed in
2.10.272.11.1· Vendor fix available
Issue
Advisory 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 ----- Original Report (Lightly edited to confirm some supposition and in the summary to use past tense) Summary nats-server did not include authorization checks on 4 separate admin-level JetStream APIs: account purge, server remove, account stream move, and account stream cancel-move. In all cases, APIs are not properly restricted to system-account users.…
Recommended action: Upgrade to 2.11.1 or 2.10.27 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NATS.io NATS Server before 2.8.2 and Streaming Server before 0.24.6 could allow a remote attacker to bypass security restrictions, caused by the failure to enforce negative user permissions in one scenario. By using a queue subscription on the wildcard, an attacker could exploit this vulnerability to allow denied subjects.
Recommended action: Upgrade to 2.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(This advisory is canonically <https://advisories.nats.io/CVE/CVE-2021-32026.txt) Problem Description The NATS server by default uses a restricted set of modern ciphersuites for TLS. This selection can be overridden through configuration. The defaults include just RSA and ECDSA with either AES/GCM with a SHA2 digest or ChaCha20/Poly1305. The configuration system allows for extensive use of CLI options to override configuration settings. When using these to set a key/cert for TLS, the restricted ciphersuite settings were lost, enabling all ciphersuites supported by Go by default. None of these additional ciphersuites are broken, so the NATS maintainers have fixed this in public git and the next release is not being hurried, nor is this security advisory embargoed. Affected versions NATS Server: All versions prior to 2.2.3 fixed with nats-io/nats-server commit ffccc2e1bd (2021-04-29) Impact If a server administrator chooses to start the nats-server with TLS configuration parameters…
Recommended action: Upgrade to 2.2.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/nats-io/nats-server/v2 >= 2.10.0, <= 2.10.3
Fixed in
2.10.4· Vendor fix available
Issue
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…
Recommended action: Upgrade to 2.10.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/nats-io/nats-server/v2 >= 2.2.0, < 2.9.23; >= 2.10.0, < 2.10.2
Fixed in
2.10.22.9.23· Vendor fix available
Issue
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…
Recommended action: Upgrade to 2.10.2 or 2.9.23 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/nats-io/nats-server/v2 >= 2.2.0, < 2.7.4
Fixed in
2.7.4· Vendor fix available
Issue
(This document is canonically: <https://advisories.nats.io/CVE/CVE-2022-26652.txt) Background NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing. JetStream is the optional RAFT-based resilient persistent feature of NATS. Problem Description The JetStream streams can be backed up and restored via NATS. The backup format is a tar archive file. Inadequate checks on the filenames within the archive file permit a so-called "Zip Slip" attack in the stream restore. NATS nats-server through 2022-03-09 (fixed in release 2.7.4) did not correctly sanitize elements of the archive file, thus a user of NATS could cause the NATS server to write arbitrary content to an attacker-controlled filename. Affected versions NATS Server: 2.2.0 up to and including 2.7.3. + Introduced with JetStream Restore functionality Fixed with nats-io/nats-server: 2.7.4 Docker image: nats <https://hub.docker.com//nats NB users of…
Recommended action: Upgrade to 2.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/nats-io/nats-server/v2 >= 2.0.0, < 2.7.2
Fixed in
2.7.2· Vendor fix available
Issue
(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…
Recommended action: Upgrade to 2.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(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…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(This advisory is canonically <https://advisories.nats.io/CVE/CVE-2020-28466.txt) Problem Description An export/import cycle between accounts could crash the nats-server, after consuming CPU and memory. This issue was fixed publicly in <https://github.com/nats-io/nats-server/pull/1731 in November 2020. The need to call this out as a security issue was highlighted by snyk.io and we are grateful for their assistance in doing so. Organizations which run a NATS service providing access to accounts run by untrusted third parties are affected. See below for an important caveat if running such a service. Affected versions 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 PR 1731, commit 2e3c226729 Impact The nats-server could be killed, after consuming resources. Workaround The import cycle requires at least two accounts to work; if you have open account sign-up, then restricting new account sign-up might hinder an…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(This advisory is canonically <https://advisories.nats.io/CVE/CVE-2020-26521.txt) Problem Description The NATS account system has an Operator trusted by the servers, which signs Accounts, and each Account can then create and sign Users within their account. The Operator should be able to safely issue Accounts to other entities which it does not fully trust. A malicious Account could create and sign a User JWT with a state not created by the normal tooling, such that decoding by the NATS JWT library (written in Go) would attempt a nil dereference, aborting execution. The NATS Server is known to be impacted by this. Affected versions JWT library all versions prior to 1.1.0 NATS Server Version 2 prior to 2.1.9 Impact JWT library Programs would nil dereference and panic, aborting execution by default. NATS server Denial of Service caused by process termination Workaround If your NATS servers do not trust any accounts which are managed by untrusted entities, then malformed User…
Recommended action: Upgrade to 2.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(This advisory is canonically https://advisories.nats.io/CVE/CVE-2020-26892.txt ) Problem Description NATS nats-server through 2020-10-07 has Incorrect Access Control because of how expired credentials are handled. The NATS accounts system has expiration timestamps on credentials; the <https://github.com/nats-io/jwt library had an API which encouraged misuse and an IsRevoked() method which misused its own API. A new IsClaimRevoked() method has correct handling and the nats-server has been updated to use this. The old IsRevoked() method now always returns true and other client code will have to be updated to avoid calling it. The CVE identifier should cover any application using the old JWT API, where the nats-server is one of those applications. Affected versions JWT library all versions prior to 1.1.0 fixed after nats-io/jwt PR 103 landed (2020-10-06) NATS Server Version 2 prior to 2.1.9 + 2.0.0 through and including 2.1.8 are vulnerable. fixed with nats-io/nats-server PRs 1632,…
Recommended action: Upgrade to 2.1.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An integer overflow in NATS Server before 2.2.0 allows a remote attacker to crash the server by sending a crafted request. Specific Go Packages Affected github.com/nats-io/nats-server/v2/server
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.