NanoMQ EUVD-2026-83050

Requires the target to be a NanoMQ broker earlier than 0.24.14 with MQTT v5 SUBSCRIBE handling reachable on the broker receive path, and a network-reachable listener the attacker can connect to. The attacker must be able to establish an MQTT session and send a SUBSCRIBE packet - feasible without credentials where anonymous access is enabled (the common default), but gated by any authentication/ACL requiring a valid client before SUBSCRIBE is processed. The malicious packet must carry a multi-byte Properties Length plus repeated SUBSCRIPTION_IDENTIFIER properties to force the incorrect offset. Reliability of an actual crash (versus a benign over-read) depends on heap layout beyond the message buffer, which is the practical limiting factor (AC:H).

This is a remote, pre-auth-capable denial-of-service in the NanoMQ broker's MQTT v5 SUBSCRIBE parsing path (heap out-of-bounds read, CWE-125). The vendor CVSS 4.0 vector (7.0, AV:N/AC:H/AT:N/PR:N/UI:N) with VC:N/VI:N/VA:N but SC:L/SI:L/SA:H frames the impact as a subsequent-system availability hit; I disagree with the scope placement - the broker process itself crashes, so the availability impact belongs on the vulnerable system (VA:H). Either way the real-world impact is a broker crash / DoS, NOT information disclosure despite the 'Information Disclosure' tag: the vendor explicitly rates confidentiality at none, and the OOB read is consumed only as a crash primitive. No EPSS score, no CISA KEV listing, and no weaponized exploit are present; only the upstream fix PR/commit and advisory exist. AC:H is defensible because reliably crashing (versus merely over-reading) depends on heap layout past the message buffer, which tempers the practical exploitation rate. Net: a legitimate availability priority for anyone exposing NanoMQ to untrusted clients, but not a mass-exploitation emergency - it is a crash bug, not RCE or data theft. Note conflicting signals to verify: vendor puts impact on subsequent system (SC/SI/SA) while the description only describes a broker crash - confirm scope intent with the vendor.

An attacker connects to an exposed NanoMQ broker (anonymous access is the default) and sends a crafted MQTT v5 SUBSCRIBE packet with a multi-byte Properties Length and repeated SUBSCRIPTION_IDENTIFIER properties. The reused len_of_varint causes get_var_integer() to start at a wrong offset and read past the heap message buffer, crashing the broker and denying service to all connected clients. No working public exploit is published, but the advisory and fix diff describe the trigger precisely.