CVE-2026-44248: Netty MQTT Decoder DoS Vulnerability

CVE-2026-44248 Overview

CVE-2026-44248 is a resource exhaustion vulnerability [CWE-400] in the Netty asynchronous network application framework. The flaw affects the MQTT 5 decoder in versions prior to 4.2.13.Final and 4.1.133.Final. The MqttDecoder parses and buffers the MQTT 5 Properties section before enforcing the maxBytesInMessage size limit. A remote attacker can submit an MQTT 5 packet containing an oversized Properties section to force excessive CPU and memory consumption on the server.

Critical Impact
A remote, unauthenticated attacker can trigger high CPU and memory usage on Netty-based MQTT 5 servers by sending a single malformed packet, leading to denial of service.

Affected Products

Netty versions prior to 4.2.13.Final
Netty versions prior to 4.1.133.Final
Applications using io.netty.handler.codec.mqtt.MqttDecoder to process MQTT 5 traffic

Discovery Timeline

2026-05-13 - CVE-2026-44248 published to NVD
2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-44248

Vulnerability Analysis

The vulnerability resides in the MQTT 5 decoding path inside Netty's MqttDecoder class. When parsing an incoming MQTT 5 CONNECT or other variable-header-bearing packet, the decoder invokes decodeVariableHeader() before the bytesRemainingBeforeVariableHeader > maxBytesInMessage check executes. The variable header decoder calls decodeProperties(), which iterates through the MQTT 5 Properties section without applying any upper bound on its size.

Because MqttDecoder extends ReplayingDecoder, the framework re-invokes the decoder repeatedly as additional bytes arrive on the socket. Each re-invocation re-parses the entire Properties section already buffered in memory. An attacker who streams a large declared Properties length forces Netty to allocate and re-process the buffered bytes until the section completes parsing, exhausting CPU cycles and heap memory.

Root Cause

The root cause is missing input validation on the size of an attacker-controlled field before allocation and parsing. The maxBytesInMessage guard exists but is positioned after the call path that buffers the Properties section. The interaction with ReplayingDecoder amplifies the cost because partial parses are repeated rather than incrementally advanced once oversized input is detected.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker connects to a Netty-based MQTT 5 broker or service and sends a packet declaring an oversized Properties section length. The decoder begins buffering and repeatedly re-parsing the bytes, consuming server resources. The vulnerability mechanism is described in the Netty GitHub Security Advisory GHSA-jfg9-48mv-9qgx. No public exploit code is associated with this CVE.

Detection Methods for CVE-2026-44248

Indicators of Compromise

Sustained high CPU utilization in Java threads executing io.netty.handler.codec.mqtt.MqttDecoder frames
Heap growth or OutOfMemoryError events in JVMs running Netty-based MQTT 5 listeners
Inbound MQTT 5 packets with abnormally large declared Properties length fields from a single source

Detection Strategies

Inspect application dependency manifests for vulnerable Netty versions below 4.2.13.Final and 4.1.133.Final using software composition analysis tooling
Capture JVM thread dumps and flame graphs during suspected incidents and look for hot frames in decodeProperties() and ReplayingDecoder.callDecode()
Deploy network monitoring rules on MQTT listener ports (typically 1883 and 8883) to flag packets with unusually large variable header lengths

Monitoring Recommendations

Alert on sudden increases in JVM heap usage, GC pause time, or CPU saturation on hosts terminating MQTT 5 traffic
Track MQTT connection error rates and decoder exception counts emitted by Netty pipelines
Correlate source IP addresses generating decoder errors with connection volume to identify abusive clients

How to Mitigate CVE-2026-44248

Immediate Actions Required

Upgrade Netty to 4.2.13.Final or 4.1.133.Final or later in all applications exposing MQTT 5 endpoints
Rebuild and redeploy downstream services and container images that bundle vulnerable Netty artifacts as transitive dependencies
Restrict network exposure of MQTT brokers to trusted clients while the upgrade is rolled out

Patch Information

The Netty project has fixed the vulnerability in versions 4.2.13.Final and 4.1.133.Final. The fix enforces the maxBytesInMessage limit before the Properties section is buffered and decoded. Patch details are documented in the Netty GitHub Security Advisory GHSA-jfg9-48mv-9qgx.

Workarounds

Place an MQTT-aware proxy or firewall in front of Netty-based brokers to drop packets with oversized variable headers
Configure strict client authentication and IP allow-lists on MQTT listeners to limit who can submit packets to the decoder
Apply per-connection CPU and memory quotas at the operating system or container level to contain resource exhaustion

bash

# Configuration example: enforce a Netty dependency override in Maven
# pom.xml dependencyManagement section
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.netty</groupId>
      <artifactId>netty-codec-mqtt</artifactId>
      <version>4.1.133.Final</version>
    </dependency>
  </dependencies>
</dependencyManagement>