CVE-2026-58214: NATS Server MQTT Authorization Bypass Exposes QoS Metadata

Technical summary

CVE-2026-58214 is an authorization bypass vulnerability in NATS Server affecting the MQTT protocol handler. Specifically, authenticated MQTT clients can subscribe to the $MQTT.deliver.pubrel internal subject family, which should be protected by the subscribe permissions enforcement layer. This family of topics carries QoS2 (Quality of Service level 2) protocol handshake data—including publish acknowledgment receipts for reliably delivered messages. The flaw stems from insufficient permission validation on internal NATS subjects accessed via MQTT, allowing an authenticated but unprivileged client to observe session metadata they should not have access to. The issue has been remediated in NATS Server 2.14.3 (current branch) and 2.12.12 (LTS branch).

Business impact

Organizations operating NATS Server as a message broker for cloud-native or edge deployments face potential information disclosure affecting account isolation. If NATS deployments enforce multi-tenancy or role-based access controls via account-level subscriptions, a lower-privileged MQTT client gains visibility into acknowledgment metadata from other sessions or applications sharing the account. This could reveal the existence, timing, and activity patterns of other message producers, though it does not expose message content itself. The risk is highest in environments where message flow patterns are considered sensitive or where regulatory controls require strict logical isolation between clients.

Affected systems

NATS Server versions 2.14.2 and earlier (except patched 2.14.3), and 2.12.11 and earlier (except patched 2.12.12). The vulnerability applies only when the MQTT protocol is enabled on the NATS Server instance. Systems running NATS Server without MQTT support, or already running the patched versions, are not affected. Verify your deployment's NATS version and active protocol modules against the vendor advisory.

Exploitability

Exploitation requires an authenticated MQTT client connection to the NATS Server—the attacker cannot exploit this as an anonymous or unauthenticated user. Once authenticated, the attack is trivial: the client simply issues a SUBSCRIBE command targeting the $MQTT.deliver.pubrel.* subject. No special tools, elevated privileges, or multi-step interaction is needed. However, the practical impact depends on deployment architecture: in single-tenant or tightly controlled environments, the risk may be low; in multi-tenant SaaS or federated edge architectures with many concurrent MQTT sessions, the exposure is more significant. The CVSS score of 4.3 reflects this: low attack complexity and low user interaction, but limited to authenticated attackers and confidentiality impact only.

Remediation

Upgrade NATS Server to version 2.14.3 or later (main branch), or 2.12.12 or later (LTS branch), depending on your deployment posture. If immediate patching is not feasible, operators should review and tighten MQTT client authentication and authorization policies to minimize the number of authenticated clients with broad subscription rights, and consider segmenting MQTT workloads by account or namespace to reduce blast radius. Confirm patch availability in the Linux Foundation NATS repository before proceeding.

Patch guidance

1. Review your current NATS Server version using the NATS CLI or by checking /version endpoint. 2. Consult the Linux Foundation NATS release notes to confirm which version branch you follow (2.14.x main or 2.12.x LTS). 3. Plan a maintenance window; rolling restart may be supported but verify in release documentation. 4. Deploy the patched version (2.14.3+ or 2.12.12+) to all NATS Server instances in your cluster. 5. Test MQTT client reconnections and subscription behavior post-upgrade to confirm no regressions. 6. Monitor logs for any authorization errors or authentication anomalies immediately after upgrade.

Detection guidance

Review NATS Server audit logs and MQTT client logs for unusual SUBSCRIBE commands targeting internal topics matching the pattern $MQTT.deliver.pubrel.*. Most MQTT clients should never subscribe to topics beginning with $; such subscriptions may indicate probing or reconnaissance. If available, enable enhanced logging on the NATS Server MQTT module to capture subscribe attempts. Check for authenticated MQTT sessions that do not correspond to known applications or service accounts. Organizations with network monitoring can watch for MQTT SUBSCRIBE packets containing internal topic names from clients that should not have visibility into protocol metadata.

Why prioritize this

This vulnerability merits prompt but measured attention. The CVSS score of 4.3 reflects a medium severity authorization bypass with confidentiality impact only—no data corruption or availability risk. However, the requirement for authentication and the context-dependent business impact (relevant mainly in multi-tenant or federated setups) suggest this is not a critical incident. Prioritize patching if you operate NATS Server with MQTT enabled and enforce strict access controls or multi-tenancy via NATS accounts. If NATS is deployed in a single-tenant edge or internal cluster, the risk is lower but patching should still occur within normal change windows.

Risk score, explained

The CVSS 3.1 score of 4.3 (MEDIUM) is driven by: AV:N (network-accessible), AC:L (no special conditions to exploit), PR:L (low privilege—any authenticated user can trigger), UI:N (no user interaction), S:U (scope unchanged), C:L (partial confidentiality loss—metadata exposed), I:N (integrity unaffected), A:N (availability unaffected). The moderate score appropriately reflects that while the vulnerability is easy to trigger for authenticated users and does leak sensitive information, it does not affect service availability or allow data modification, and it is confined to a specific protocol handler.

Frequently asked questions