CVE-2025-66023: 
NixOS vulnerability analysis and mitigation

CVE-2025-66023 is a Heap-Use-After-Free (UAF) vulnerability in the MQTT bridge client component of NanoMQ MQTT Broker, affecting all versions prior to 0.24.5. The flaw resides in the underlying NanoNNG library and is triggered when NanoMQ acts as a bridge client connecting to a remote MQTT broker. It was discovered by researcher lucajungnickel, reported on October 14, 2025, and publicly disclosed on January 1, 2026. The vulnerability carries a CVSS v3.1 base score of 4.9 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory).

The root cause is a Use After Free condition (CWE-416) in the MQTT client SDK embedded within NanoMQ's NanoNNG library. When NanoMQ initiates a bridge connection to a remote broker, the client SDK does not enforce that CONNACK is the first packet received; a malicious broker can accept the connection and immediately send a malformed (non-CONNACK) packet sequence, causing state confusion that results in access to already-freed heap memory. Exploitation requires the attacker to control or compromise a remote MQTT broker that a NanoMQ instance is configured to bridge to, meaning the attacker must have high privileges (i.e., operate the remote broker endpoint). The fix, merged in NanoNNG PR #1365 on October 14, 2025, enforces that CONNACK is always the first packet processed in the connection handshake (GitHub Advisory, NanoNNG PR).

Successful exploitation causes the NanoMQ broker process to crash (Denial of Service) or potentially results in memory corruption, which could theoretically be leveraged for further exploitation. There is no confidentiality or integrity impact identified — the primary risk is availability loss of the edge messaging platform. In IoT or industrial deployments where NanoMQ serves as a critical edge messaging bridge, a crash could disrupt data pipelines and downstream systems relying on MQTT message delivery (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.036%, reflecting a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained by the requirement that the attacker must control a remote MQTT broker that the target NanoMQ instance is configured to bridge to, significantly limiting the attack surface (GitHub Advisory, Feedly).

1. Setup malicious broker: Deploy a rogue MQTT broker (e.g., a custom server or modified open-source broker) that the attacker controls, accessible over the network.
2. Induce bridge configuration: Ensure the target NanoMQ instance is configured to bridge to the attacker-controlled broker — this may require compromising the NanoMQ configuration or social engineering an administrator into adding the malicious broker as a bridge target.
3. Accept incoming connection: When NanoMQ initiates the bridge connection, the malicious broker accepts the TCP/MQTT connection.
4. Send malformed packet sequence: Immediately after accepting the connection (before or instead of sending a valid CONNACK), the malicious broker sends a crafted, malformed MQTT packet sequence that violates the expected protocol handshake order.
5. Trigger UAF: NanoMQ's MQTT client SDK processes the unexpected packet without enforcing CONNACK-first ordering, causing state confusion and a Heap-Use-After-Free condition, resulting in a crash (DoS) or potential memory corruption (GitHub Advisory, NanoNNG PR).

• Logs: NanoMQ process logs showing unexpected crash or segmentation fault shortly after establishing a bridge connection to a remote broker; error messages referencing heap corruption or invalid memory access in the NanoNNG transport layer.
• Process: Unexpected termination (crash) of the nanomq process, particularly correlated with bridge connection events to external brokers.
• Network: Bridge connection attempts to unfamiliar or newly added remote MQTT broker endpoints (unusual destination IPs/hostnames on MQTT port 1883 or 8883); rapid connection-then-disconnect sequences from the remote broker side.
• File System: Core dump files generated by the NanoMQ process following a crash, which may contain heap memory artifacts useful for forensic analysis (GitHub Issue, GitHub Advisory).

Upgrade NanoMQ to version 0.24.5 or later, which includes the fix from NanoNNG PR #1365 enforcing CONNACK-first packet ordering in the MQTT client SDK. As an interim workaround, validate and restrict remote brokers that NanoMQ bridges to — only allow connections to trusted, verified broker endpoints. Additionally, implement network-level controls (e.g., firewall rules or allowlists) to restrict which external broker addresses NanoMQ instances can connect to, reducing exposure to attacker-controlled brokers (GitHub Advisory, NanoNNG PR).

The vulnerability was credited to researcher lucajungnickel and disclosed via GitHub Security Advisories by NanoMQ maintainer JaylinYu on January 1, 2026. Red Hat tracked the CVE through their security advisory system. No significant broader media coverage or notable community debate has been identified beyond standard vulnerability tracking platforms (GitHub Advisory, Red Hat).