Netty EUVD-2026-82869

Requires the target application to run a Netty pipeline that includes io.netty.handler.codec.mqtt.MqttDecoder and to expose an MQTT listener reachable by the attacker - i.e., an MQTT broker/gateway endpoint accepting CONNECT packets. Given that, exploitation is remote and unauthenticated (PR:N, UI:N) against default decoder behavior, since even a configured maxBytesInMessage limit is bypassed by the Properties Length trick. The primary LIMITING factor is deployment: MQTT is a specialized protocol, so only environments that deliberately expose Netty-based MQTT services (a subset of the listed Red Hat AMQ Broker / Fuse / Camel / EAP / SSO products) are affected; plain HTTP or non-MQTT Netty usage is not.

This is a genuine but bounded priority. The CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects an unauthenticated, network-reachable, low-complexity availability attack with no confidentiality or integrity impact - a pure denial-of-service. The 'High' rating is driven entirely by A:H (OutOfMemoryError). No EPSS score, KEV listing, or public POC was provided, so there is no signal of active or widespread exploitation - status is 'no public exploit identified at time of analysis.' No SSVC decision data was supplied. The key qualifier the raw CVSS omits: exploitation requires the target application to expose a Netty-based MQTT listener with the MqttDecoder in its pipeline, which is far less common than a generic HTTP endpoint. This is notably an INCOMPLETE FIX of CVE-2026-44248 - the prior patch guarded Remaining Length but not Properties Length - which raises the likelihood that a knowledgeable attacker who studied the original fix could reconstruct the bypass. Net: real and worth patching promptly on any MQTT-facing deployment, but the niche protocol surface tempers real-world exposure versus the 7.5 number.

An unauthenticated attacker connects to an exposed MQTT endpoint served by a Netty-based broker or gateway (e.g., Red Hat AMQ Broker or a Camel/JBoss integration) and sends a single crafted CONNECT packet carrying a small Remaining Length but an enormous Properties Length. The MqttDecoder's size check (which only validates Remaining Length) passes, so ReplayingDecoder keeps buffering network bytes and parsing millions of UserProperty objects, exhausting heap and CPU until the JVM throws OutOfMemoryError. No public exploit code was identified, but the mechanism is fully described in the advisory and derives from a known incompletely-patched flaw.