CVE-2026-33216: 
NixOS vulnerability analysis and mitigation

CVE-2026-33216 is an information disclosure vulnerability in NATS-Server affecting MQTT deployments that use username/password authentication. In vulnerable versions, MQTT passwords are incorrectly classified as non-authenticating identity statements (JWTs) and are subsequently exposed in plaintext via the server's monitoring endpoints. The vulnerability affects all NATS-Server versions prior to 2.11.15 and versions 2.12.0 through 2.12.5. It was published on March 24, 2026, with patches released between March 24–26, 2026. The CVSS v3.1 base score is 8.6 (High) with a scope change, reflecting network-accessible exposure with no authentication required (GitHub Advisory, NATS Security Advisory).

The root cause is a logic error in the MQTT connection handling code (server/mqtt.go) where the MQTT client password was directly assigned to c.opts.JWT — a field intended for JWT tokens — causing it to be treated as a non-authenticating identity statement and surfaced through monitoring endpoints (CWE-256: Plaintext Storage of a Password; CWE-213: Exposure of Sensitive Information Due to Incompatible Policies). The fix, applied in commit b5b63cf, introduces a local ujwt variable to hold the JWT value separately, only populating c.opts.JWT after confirming the credential is a valid JWT and not a raw password (GitHub Commit). Exploitation requires that an attacker can reach the NATS monitoring HTTP endpoint, which is a separate port from the main NATS/MQTT listener and is not authenticated by default (GitHub Advisory).

An unauthenticated attacker with network access to the NATS monitoring endpoint can retrieve MQTT client passwords in plaintext, enabling unauthorized access to the MQTT messaging infrastructure. This has a high confidentiality impact with a changed scope, meaning the exposure extends beyond the NATS server itself to any systems or services relying on MQTT authentication. Integrity and availability are not directly affected, but credential theft could enable lateral movement into connected IoT, cloud, or edge systems that rely on MQTT for communication (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is approximately 0.05% (16th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack requires no authentication and no user interaction, making it trivially exploitable against any NATS deployment where the monitoring endpoint is internet-exposed or accessible to untrusted users (GitHub Advisory).

1. Reconnaissance: Identify NATS-Server instances running MQTT with exposed monitoring endpoints using network scanners (e.g., Shodan, Censys, or nmap). The default NATS monitoring port is 8222.
2. Verify monitoring endpoint access: Send an HTTP GET request to http://<target>:8222/ to confirm the monitoring endpoint is accessible and unauthenticated.
3. Query connected clients: Send a GET request to http://<target>:8222/connz or a similar monitoring endpoint that lists connected client details, including connection options.
4. Extract MQTT passwords: Parse the JSON response for MQTT client entries where the jwt field contains the client's plaintext password (incorrectly stored there due to the logic flaw).
5. Authenticate to MQTT: Use the recovered credentials to authenticate directly to the NATS MQTT interface (default port 1883 or 8883 for TLS) and gain unauthorized access to MQTT topics and messages (GitHub Advisory, GitHub Commit).

• Network: Unexpected or repeated HTTP GET requests to the NATS monitoring port (default 8222), particularly to endpoints such as /connz, /subsz, or /varz, from external or untrusted IP addresses.
• Logs: NATS server access logs showing unauthenticated HTTP requests to monitoring endpoints from IPs not belonging to authorized administrators.
• Network: Subsequent MQTT authentication attempts (port 1883/8883) from IP addresses that previously queried the monitoring endpoint, potentially indicating credential harvesting followed by unauthorized login.
• Process/Config: NATS monitoring endpoint bound to 0.0.0.0 or a public interface rather than 127.0.0.1, indicating a misconfiguration that enables exploitation (GitHub Advisory).

Upgrade NATS-Server to version 2.11.15 or 2.12.6 (or later), which contain the fix for this vulnerability (GitHub Advisory, NATS Security Advisory). As an immediate workaround for those unable to patch, restrict access to the monitoring endpoint by binding it only to localhost (127.0.0.1) or protecting it with network-level controls (firewall rules, VPN, or reverse proxy with authentication). The monitoring endpoint should never be exposed to the internet or untrusted network segments. Microsoft's Azure Linux 3 Telegraf package (azl3_telegraf_1.31.0-17) is also listed as an affected product and should be updated accordingly (Microsoft MSRC).

The advisory was published by philpennock on the NATS GitHub repository on March 24, 2026, and quickly picked up by security news outlets including The Hacker Wire. Red Hat opened a tracking bug (Bugzilla #2451448) with high severity, and openSUSE issued a security announcement for affected packages. Social media coverage on Mastodon and Bluesky noted the straightforward nature of the exposure — a logic error causing passwords to leak through an unauthenticated HTTP endpoint — with community sentiment emphasizing the importance of not exposing monitoring endpoints to untrusted networks (Red Hat Bugzilla, GitHub Advisory).