CVE-2026-93575 in Netty
Summary
by MITRE • 09/18/2026
### 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.
#
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Netty relates to an incomplete implementation of input validation within its MQTT protocol decoder, specifically addressing CVE-2026-44248. While the initial fix attempted to mitigate resource exhaustion by enforcing a maximum message size limit defined as maxBytesInMessage, it failed to account for all components of the MQTT packet structure that contribute to memory consumption. The MQTT specification defines packets with variable headers and properties that can contain significant amounts of data. In this scenario, the decoder correctly checks if the Remaining Length field exceeds the configured threshold but neglects to validate whether the Properties Length field is consistent with or bounded by that same limit. This oversight creates a logical flaw where an attacker can craft a malicious MQTT CONNECT packet that appears small according to the primary size check yet contains a massive amount of property data, thereby bypassing the intended protection mechanisms and leading to severe system instability.
From a technical perspective, the root cause lies in the io.netty.handler.codec.mqtt.MqttDecoder class, particularly within its decode logic and the helper method responsible for parsing MQTT properties. When processing an incoming packet, the decoder reads the total length of the properties section from the variable header. If the network buffer does not yet contain all the bytes indicated by this Properties Length value, Netty's ReplayingDecoder mechanism is triggered to buffer additional data from the socket until sufficient information is available for parsing. Because the initial validation only compares the Remaining Length against maxBytesInMessage, a packet with a small Remaining Length but an excessively large Properties Length passes the check. Consequently, the decoder proceeds to allocate memory and parse millions of UserProperty objects in an attempt to fulfill the requested length, resulting in unbounded resource consumption that quickly exhausts available heap space and CPU cycles on the server side.
The operational impact of this vulnerability is significant for any service relying on Netty’s MQTT handler for message brokering or client communication. An unauthenticated remote attacker can exploit this flaw by sending specially crafted CONNECT packets to trigger an OutOfMemoryError condition, effectively causing a denial of service against the affected application. This type of attack does not require authentication credentials and can be executed with minimal network bandwidth since the payload structure is small while the parsing overhead is massive. The resulting system instability may lead to crashes or unresponsive services, disrupting critical IoT communications, real-time data streaming, or any other infrastructure dependent on MQTT connectivity managed by Netty.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-400 Uncontrolled Resource Consumption as defined in the Common Weakness Enumeration database. In terms of offensive security frameworks, it corresponds to MITRE ATT&CK technique T1496 Resource Hijacking, where an attacker consumes system resources to degrade performance or cause a denial of service. To mitigate this risk, developers must ensure that all variable-length fields within MQTT packets are validated against the global message size limits before any parsing or buffering operations commence. Specifically, the Properties Length field should be checked to ensure it does not exceed the remaining allowable bytes after accounting for other packet components and headers. Upgrading to a patched version of Netty that addresses this specific validation gap is essential, along with implementing additional defensive measures such as strict connection rate limiting and monitoring for anomalous memory usage patterns associated with MQTT connections.