Mqtt
Monthly
Remote denial of service in the Aedes MQTT broker through version 1.1.0 lets any client able to open an MQTT session crash the broker process with a single over-deep PUBLISH or SUBSCRIBE topic, or by registering a Will message with such a topic that fires on ungraceful disconnect. The crash comes from a synchronous 'too many words' throw inside the qlobber topic matcher that Aedes does not catch, so it reaches the Node.js event loop and terminates the process, disconnecting every connected client and blocking reconnection until restart. The vendor advisory includes a public proof-of-concept script that reliably kills the official moscajs/aedes Docker image on the first packet; the fix ships in 1.1.1 as a topic-level guard defaulting to 100 levels.
An out-of-bounds read in Eclipse ThreadX NetX Duo's MQTT-over-WebSocket transport (the setter path) lets a malicious or compromised broker - or a man-in-the-middle on the WebSocket connection - crash the embedded network stack and potentially disclose a limited amount of adjacent memory. Affected builds are NetX Duo 6.4.4 through 6.5.1.202602, and only firmware that actually compiles in and uses the MQTT client over WebSocket is exposed; devices running plain MQTT/TCP or no MQTT are unaffected. Exploitation is not confirmed as active (not in CISA KEV) and no public exploit code has been identified at time of analysis, but CISA SSVC rates the issue Automatable with partial technical impact, so the practical risk is a conditional availability problem rather than an emergency, with a confidentiality impact the vendor's original CVSS score omits but which the independent assessment reflects as C:L/A:H.
Malformed MQTT PUBLISH frames leak packet buffers in the Eclipse ThreadX NetX Duo MQTT client, letting a peer that can deliver a few dozen such messages exhaust the network driver's receive pool and halt all inbound traffic on the device until it is rebooted. Only builds including the NetX Duo MQTT client are exposed, and delivery requires broker control, a man-in-the-middle position on the MQTT session, or publish rights on a topic the client subscribes to, which is why the impact is availability-only (CVSS 4.0 base 8.2; assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) despite a network attack vector. No public exploit code and no confirmed active exploitation have been identified at time of analysis.
Remote unauthenticated clients can crash a Moquette MQTT broker running 0.18.0 or earlier by publishing or subscribing with a topic name or filter that is nested to an extreme depth, triggering uncontrolled recursion in the broker's CTrie subscription structure and an uncaught StackOverflowError. Because Moquette accepts anonymous MQTT clients by default, network reachability is the only precondition, and the resulting crash lands on a SessionEventLoop that catches only InterruptedException and is never restarted, so the failure wedges every session co-located on that loop rather than just the attacker's connection - a broker-wide denial of service with high availability impact (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor-published CVSS 4.0 base 8.7). The issue is not in CISA KEV and no public exploit identified at time of analysis; it is fixed in Moquette 0.18.1, which introduces a MAX_TOPIC_DEPTH of 1024 enforced on both PUBLISH and SUBSCRIBE paths.
An out-of-bounds write in the MQTT client module of the lwIP TCP/IP stack lets an adversary who controls or impersonates the MQTT broker that a device connects to corrupt heap/stack memory and potentially achieve full code execution on that device. Only devices built with lwIP's optional MQTT client compiled in are exposed, and because MQTT connections are client-initiated the device is not directly reachable inbound: the attacker must operate a malicious broker, compromise the legitimate broker, or hold a man-in-the-middle position on the client-to-broker path (feasible where TLS is absent or certificate validation is disabled). No authentication or user interaction is required once that broker-side position is achieved, but no public exploit code has been identified at time of analysis and no CISA KEV listing exists; the vendor CVSS 4.0 score of 9.3 (AV:N/AC:L/AT:N) presents this as trivially exploitable, whereas the assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects the significant broker-control/MITM prerequisite.
Moquette MQTT brokers running versions prior to 0.18.1 fail to enforce topic write ACLs on Last Will and Testament messages, letting a remote, unauthenticated client (CVSS vector contains PR:N) publish attacker-controlled payloads into ACL-protected topics it is not permitted to write to. The attacker sets a restricted topic as the Will Topic in the CONNECT packet and then drops the connection abnormally (for example with a TCP RST) so the broker fires the Will through PostOffice.publishWill() → publish2Subscribers() without ever calling authorizator.canWrite(), the check that guards normal QoS 0/1/2 PUBLISH paths. The published CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N); our independent assessment concurs on network reachability, no privileges and no user interaction, with integrity-only impact, though it rates the per-event integrity effect as low because each bypass delivers only a single message (repeatable by reconnecting). No public exploit code and no confirmed active exploitation were identified at time of analysis; the issue is fixed in 0.18.1.
Hardcoded MQTT credentials shipped inside Bransys ELD grant unauthenticated read access to real-time telemetry for every active device belonging to a subset of carriers connected to the affected MQTT broker. Because the static credential is embedded in the product, remote attackers who recover it - for example by reverse-engineering the shipped binary or firmware - can subscribe to the broker with any standard MQTT client, and no user interaction or per-victim authentication is required (PR:N/UI:N). The exposure is confidentiality-only against live fleet data (C:H/I:N/A:N in our assessed CVSS 3.1 vector) and no public exploit code or confirmed active exploitation was identified at time of analysis; the reported CVSS 4.0 score of 8.7 reflects the broad device population reachable with a single shared credential, and CISA ICS advisory ICSA-26-260-01 documents the issue.
Improper TLS hostname validation in the MQTT client layer of AWS IoT Device SDK for Python (AWSIoTPythonSDK) 1.5.3 through 1.6.0 running on Python 3.7 and later allows an adversary-in-the-middle who possesses a certificate issued for an unrelated hostname by a certificate authority already in the device trust store to impersonate the AWS IoT Core endpoint, read device telemetry, and inject MQTT messages that the device processes as authentic. This is not exploitable from an arbitrary internet location: the attacker must hold an on-path position and a trusted-CA certificate for an unrelated hostname. No public exploit was identified at time of analysis, and the vendor has released 1.6.1 to enforce hostname verification.
Denial of service in RabbitMQ's MQTT plugin lets an authenticated publisher using MQTT 5 force a single victim subscriber's connection to be dropped. Because the parser accepts the CONNECT-only Request-Problem-Information property on PUBLISH packets and the broker then routes it to matching subscribers, the outbound serialization path hits a missing clause in serialise_prop/2 and raises an uncontained function_clause that closes the victim's MQTT or Web MQTT connection. Exploitation requires valid broker credentials with topic-write permission on a topic that at least one other client subscribes to, and the broker, the publisher connection, and all other clients remain available; no public exploit code was identified at time of analysis, and no confirmed active exploitation (CISA KEV) has been reported.
Authorization bypass in RabbitMQ's MQTT topic permission handling allows a low-privileged authenticated user to broaden read and write access to topics when an operator-defined permission template embeds the {clientid} variable inside a regex character class. The flaw is an incomplete fix for CVE-2026-44838, where the escaperegexchar/1 function fails to escape the hyphen, enabling a malicious clientid to alter the character class and bypass intended topic authorization. Affected versions include RabbitMQ 4.0.0 through 4.3.2, 4.0.x before 4.0.23, 4.1.x before 4.1.14, and 4.2.x before 4.2.9; the vendor rates this medium severity (CVSS 5.1), and no public exploit code has been identified at time of analysis.
Loopback source-address restriction bypass in RabbitMQ's native MQTT and MQTT-over-WebSocket listeners (all releases from 3.13.0 up to the fixed versions 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.3) allows an authenticated attacker holding valid credentials for a loopback-restricted account to reach that account from a non-loopback address. The flaw only manifests when such a listener runs behind a trusted frontend that speaks PROXY Protocol: the proxy-derived client address is dropped before the MQTT authentication path evaluates the loopback_users setting, so the frontend-to-broker connection is mistakenly judged as loopback. Password authentication itself is not bypassed, CVSS 4.0 base is 6.0 with high attack complexity and a present attack requirement reflecting how deployment-specific the trigger is, no public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV listing).
The NanoMQ MQTT client (versions prior to 0.24.14) can be hung and driven into a CPU- and memory-consuming infinite loop by a malicious or compromised MQTT broker that replies to a client UNSUBSCRIBE exchange with a malformed packet containing a zero-length topic followed by trailing data. The defect is CWE-835 in nni_mqtt_msg_decode_unsubscribe() (nng/src/supplemental/mqtt/mqtt_codec.c), where a failed read_uint16() during topic counting leaves buf.curpos unchanged while topic_count keeps incrementing, so the parse loop never terminates; when automatic reconnection is enabled the client re-enters the same state repeatedly, producing a sustained denial of service against the client itself. The independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L - a low-impact, low-priority availability issue with an inverted threat model, since the victim is the client and the attacker must supply the hostile endpoint; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 0.24.14.
NanoMQ MQTT brokers prior to 0.24.14 can be driven unresponsive by a remote unauthenticated client that sends MQTT v5 PUBLISH or SUBSCRIBE packets containing a large number of User Properties. Each property is inserted via property_append(), which re-walks the entire linked list, so a single packet with many properties forces quadratic (O(N²)) CPU work in the decoder; repeating the packet sustains the denial of service. The vendor has released a fix in 0.24.14, and no public exploit code or confirmed active exploitation has been identified at time of analysis; impact is availability-only and rated low, with the independent assessment noting that effectiveness depends on how many properties can be packed into a packet and on continued resending.
Authenticated users of FlashMQ MQTT brokers running versions prior to 1.23.2 can cause a gradual memory leak by creating sessions that accumulate QoS messages which are never delivered to a connected client; the queued publish entries are not released even after the session eventually expires. The result is slow, cumulative memory growth that can degrade broker stability over time rather than an immediate crash (CVSS 4.3, A:L), and exploitation requires valid credentials (PR:L). No public exploit code has been identified at time of analysis and there is no confirmed active exploitation; EPSS is low at 0.34% (25th percentile), and the vendor has released a fix in 1.23.2.
The MQTT protocol 3.1.1 requires a server to set a timeout value of 1.5 times the Keep-Alive value specified by a client, which allows remote attackers to cause a denial of service (loss of the. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Remote denial of service in the Aedes MQTT broker through version 1.1.0 lets any client able to open an MQTT session crash the broker process with a single over-deep PUBLISH or SUBSCRIBE topic, or by registering a Will message with such a topic that fires on ungraceful disconnect. The crash comes from a synchronous 'too many words' throw inside the qlobber topic matcher that Aedes does not catch, so it reaches the Node.js event loop and terminates the process, disconnecting every connected client and blocking reconnection until restart. The vendor advisory includes a public proof-of-concept script that reliably kills the official moscajs/aedes Docker image on the first packet; the fix ships in 1.1.1 as a topic-level guard defaulting to 100 levels.
An out-of-bounds read in Eclipse ThreadX NetX Duo's MQTT-over-WebSocket transport (the setter path) lets a malicious or compromised broker - or a man-in-the-middle on the WebSocket connection - crash the embedded network stack and potentially disclose a limited amount of adjacent memory. Affected builds are NetX Duo 6.4.4 through 6.5.1.202602, and only firmware that actually compiles in and uses the MQTT client over WebSocket is exposed; devices running plain MQTT/TCP or no MQTT are unaffected. Exploitation is not confirmed as active (not in CISA KEV) and no public exploit code has been identified at time of analysis, but CISA SSVC rates the issue Automatable with partial technical impact, so the practical risk is a conditional availability problem rather than an emergency, with a confidentiality impact the vendor's original CVSS score omits but which the independent assessment reflects as C:L/A:H.
Malformed MQTT PUBLISH frames leak packet buffers in the Eclipse ThreadX NetX Duo MQTT client, letting a peer that can deliver a few dozen such messages exhaust the network driver's receive pool and halt all inbound traffic on the device until it is rebooted. Only builds including the NetX Duo MQTT client are exposed, and delivery requires broker control, a man-in-the-middle position on the MQTT session, or publish rights on a topic the client subscribes to, which is why the impact is availability-only (CVSS 4.0 base 8.2; assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) despite a network attack vector. No public exploit code and no confirmed active exploitation have been identified at time of analysis.
Remote unauthenticated clients can crash a Moquette MQTT broker running 0.18.0 or earlier by publishing or subscribing with a topic name or filter that is nested to an extreme depth, triggering uncontrolled recursion in the broker's CTrie subscription structure and an uncaught StackOverflowError. Because Moquette accepts anonymous MQTT clients by default, network reachability is the only precondition, and the resulting crash lands on a SessionEventLoop that catches only InterruptedException and is never restarted, so the failure wedges every session co-located on that loop rather than just the attacker's connection - a broker-wide denial of service with high availability impact (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; vendor-published CVSS 4.0 base 8.7). The issue is not in CISA KEV and no public exploit identified at time of analysis; it is fixed in Moquette 0.18.1, which introduces a MAX_TOPIC_DEPTH of 1024 enforced on both PUBLISH and SUBSCRIBE paths.
An out-of-bounds write in the MQTT client module of the lwIP TCP/IP stack lets an adversary who controls or impersonates the MQTT broker that a device connects to corrupt heap/stack memory and potentially achieve full code execution on that device. Only devices built with lwIP's optional MQTT client compiled in are exposed, and because MQTT connections are client-initiated the device is not directly reachable inbound: the attacker must operate a malicious broker, compromise the legitimate broker, or hold a man-in-the-middle position on the client-to-broker path (feasible where TLS is absent or certificate validation is disabled). No authentication or user interaction is required once that broker-side position is achieved, but no public exploit code has been identified at time of analysis and no CISA KEV listing exists; the vendor CVSS 4.0 score of 9.3 (AV:N/AC:L/AT:N) presents this as trivially exploitable, whereas the assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects the significant broker-control/MITM prerequisite.
Moquette MQTT brokers running versions prior to 0.18.1 fail to enforce topic write ACLs on Last Will and Testament messages, letting a remote, unauthenticated client (CVSS vector contains PR:N) publish attacker-controlled payloads into ACL-protected topics it is not permitted to write to. The attacker sets a restricted topic as the Will Topic in the CONNECT packet and then drops the connection abnormally (for example with a TCP RST) so the broker fires the Will through PostOffice.publishWill() → publish2Subscribers() without ever calling authorizator.canWrite(), the check that guards normal QoS 0/1/2 PUBLISH paths. The published CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N); our independent assessment concurs on network reachability, no privileges and no user interaction, with integrity-only impact, though it rates the per-event integrity effect as low because each bypass delivers only a single message (repeatable by reconnecting). No public exploit code and no confirmed active exploitation were identified at time of analysis; the issue is fixed in 0.18.1.
Hardcoded MQTT credentials shipped inside Bransys ELD grant unauthenticated read access to real-time telemetry for every active device belonging to a subset of carriers connected to the affected MQTT broker. Because the static credential is embedded in the product, remote attackers who recover it - for example by reverse-engineering the shipped binary or firmware - can subscribe to the broker with any standard MQTT client, and no user interaction or per-victim authentication is required (PR:N/UI:N). The exposure is confidentiality-only against live fleet data (C:H/I:N/A:N in our assessed CVSS 3.1 vector) and no public exploit code or confirmed active exploitation was identified at time of analysis; the reported CVSS 4.0 score of 8.7 reflects the broad device population reachable with a single shared credential, and CISA ICS advisory ICSA-26-260-01 documents the issue.
Improper TLS hostname validation in the MQTT client layer of AWS IoT Device SDK for Python (AWSIoTPythonSDK) 1.5.3 through 1.6.0 running on Python 3.7 and later allows an adversary-in-the-middle who possesses a certificate issued for an unrelated hostname by a certificate authority already in the device trust store to impersonate the AWS IoT Core endpoint, read device telemetry, and inject MQTT messages that the device processes as authentic. This is not exploitable from an arbitrary internet location: the attacker must hold an on-path position and a trusted-CA certificate for an unrelated hostname. No public exploit was identified at time of analysis, and the vendor has released 1.6.1 to enforce hostname verification.
Denial of service in RabbitMQ's MQTT plugin lets an authenticated publisher using MQTT 5 force a single victim subscriber's connection to be dropped. Because the parser accepts the CONNECT-only Request-Problem-Information property on PUBLISH packets and the broker then routes it to matching subscribers, the outbound serialization path hits a missing clause in serialise_prop/2 and raises an uncontained function_clause that closes the victim's MQTT or Web MQTT connection. Exploitation requires valid broker credentials with topic-write permission on a topic that at least one other client subscribes to, and the broker, the publisher connection, and all other clients remain available; no public exploit code was identified at time of analysis, and no confirmed active exploitation (CISA KEV) has been reported.
Authorization bypass in RabbitMQ's MQTT topic permission handling allows a low-privileged authenticated user to broaden read and write access to topics when an operator-defined permission template embeds the {clientid} variable inside a regex character class. The flaw is an incomplete fix for CVE-2026-44838, where the escaperegexchar/1 function fails to escape the hyphen, enabling a malicious clientid to alter the character class and bypass intended topic authorization. Affected versions include RabbitMQ 4.0.0 through 4.3.2, 4.0.x before 4.0.23, 4.1.x before 4.1.14, and 4.2.x before 4.2.9; the vendor rates this medium severity (CVSS 5.1), and no public exploit code has been identified at time of analysis.
Loopback source-address restriction bypass in RabbitMQ's native MQTT and MQTT-over-WebSocket listeners (all releases from 3.13.0 up to the fixed versions 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.3) allows an authenticated attacker holding valid credentials for a loopback-restricted account to reach that account from a non-loopback address. The flaw only manifests when such a listener runs behind a trusted frontend that speaks PROXY Protocol: the proxy-derived client address is dropped before the MQTT authentication path evaluates the loopback_users setting, so the frontend-to-broker connection is mistakenly judged as loopback. Password authentication itself is not bypassed, CVSS 4.0 base is 6.0 with high attack complexity and a present attack requirement reflecting how deployment-specific the trigger is, no public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV listing).
The NanoMQ MQTT client (versions prior to 0.24.14) can be hung and driven into a CPU- and memory-consuming infinite loop by a malicious or compromised MQTT broker that replies to a client UNSUBSCRIBE exchange with a malformed packet containing a zero-length topic followed by trailing data. The defect is CWE-835 in nni_mqtt_msg_decode_unsubscribe() (nng/src/supplemental/mqtt/mqtt_codec.c), where a failed read_uint16() during topic counting leaves buf.curpos unchanged while topic_count keeps incrementing, so the parse loop never terminates; when automatic reconnection is enabled the client re-enters the same state repeatedly, producing a sustained denial of service against the client itself. The independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L - a low-impact, low-priority availability issue with an inverted threat model, since the victim is the client and the attacker must supply the hostile endpoint; no public exploit code was identified at time of analysis and the issue is not in CISA KEV. Vendor-released patch: 0.24.14.
NanoMQ MQTT brokers prior to 0.24.14 can be driven unresponsive by a remote unauthenticated client that sends MQTT v5 PUBLISH or SUBSCRIBE packets containing a large number of User Properties. Each property is inserted via property_append(), which re-walks the entire linked list, so a single packet with many properties forces quadratic (O(N²)) CPU work in the decoder; repeating the packet sustains the denial of service. The vendor has released a fix in 0.24.14, and no public exploit code or confirmed active exploitation has been identified at time of analysis; impact is availability-only and rated low, with the independent assessment noting that effectiveness depends on how many properties can be packed into a packet and on continued resending.
Authenticated users of FlashMQ MQTT brokers running versions prior to 1.23.2 can cause a gradual memory leak by creating sessions that accumulate QoS messages which are never delivered to a connected client; the queued publish entries are not released even after the session eventually expires. The result is slow, cumulative memory growth that can degrade broker stability over time rather than an immediate crash (CVSS 4.3, A:L), and exploitation requires valid credentials (PR:L). No public exploit code has been identified at time of analysis and there is no confirmed active exploitation; EPSS is low at 0.34% (25th percentile), and the vendor has released a fix in 1.23.2.
The MQTT protocol 3.1.1 requires a server to set a timeout value of 1.5 times the Keep-Alive value specified by a client, which allows remote attackers to cause a denial of service (loss of the. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.