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