CVE-2026-93575: Netty: netty-codec-mqtt: io.netty/netty-codec-mqtt: netty: resource exhaustion in mqttdecoder
Summary Netty's fix for CVE-2026-44248 is incomplete. The decoder checks if the MQTT packet's Remaining Length exceeds maxBytesInMessage, but fails to validate the Properties Length against the Remaining Length. An attacker can bypass the size limit by sending a small Remaining Length but an enormous Properties Length. This forces Netty to buffer and parse millions of properties, allowing an unauthenticated remote attacker to trigger excessive memory and CPU consumption, leading to OutOfMemoryError. Details In io.netty.handler.codec.mqtt.MqttDecoder, the decodeProperties() helper method reads totalPropertiesLength and attempts to parse that many bytes. If the buffer lacks the full length, a Signal is thrown. The catch block inside decode() only enforces maxBytesInMessage against bytesRemainingBeforeVariableHeader (the packet's Remaining Length). By sending a CONNECT packet with a small Remaining Length but a huge Properties Length, the size check passes. ReplayingDecoder then buffers data from the network until the huge Properties Length is reached, parsing millions of UserProperty objects and exhausting CPU and memory. #
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to remote exploitation?
Deployments that accept MQTT traffic through Netty's MQTT decoder are exposed to an unauthenticated remote attacker that can send crafted packets to the service.
Does the maxBytesInMessage limit prevent this attack?
No. The decoder enforces maxBytesInMessage against the packet Remaining Length, but does not validate Properties Length against that value, allowing the limit to be bypassed.
Does an attacker need valid credentials or a completed MQTT session?
No. The described attack uses a crafted CONNECT packet and can be performed by an unauthenticated remote attacker.