Organizations running IoT devices, industrial sensors, or embedded systems built on MQTT-C face two concrete risks: availability loss from client process crashes and potential memory disclosure from adjacent heap contents, which may include application credentials, telemetry data, or configuration values depending on what the affected process handles. The attack requires only network access to an MQTT session — no credentials — making it accessible to opportunistic attackers on unsegmented networks. For organizations in manufacturing, logistics, healthcare, or utilities where MQTT-based IoT underpins operational technology, a successful crash campaign could disrupt monitoring, alerting, or control functions.
You Are Affected If
You run software or firmware that includes LiamBindle MQTT-C version 1.1.6 or earlier
Your MQTT-C clients connect to MQTT brokers over unencrypted sessions (plaintext port 1883)
Your MQTT broker is reachable by untrusted parties, or your network is not fully segmented from external access
You do not have an up-to-date software bill of materials (SBOM) and cannot confirm whether MQTT-C is present in your dependency tree or firmware images
You have not applied a patched version of MQTT-C as released by the upstream maintainer
Board Talking Points
A flaw in a widely used embedded messaging library allows an attacker with network access to crash IoT and industrial devices and potentially read sensitive data from device memory.
Security teams should identify all devices and applications using this library within the next 5 business days and apply available patches or enforce encrypted, authenticated broker connections as an interim control.
Without action, internet-accessible or poorly segmented IoT systems remain vulnerable to denial-of-service and memory disclosure by any attacker who can reach the network traffic.
