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

# 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>