Description

Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.137.Final and 4.2.17.Final, MqttEncoder does not validate client identifiers, will topics, usernames, and PUBLISH topic names before encoding, allowing prohibited null bytes in MQTT UTF-8 string fields and potentially causing routing, access-control, or identity mismatches in downstream brokers. The vulnerability is exploitable when an application uses Netty's MQTT encoder to construct messages from user-controlled input. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.5",
  "pubDate": "2026-08-24T20:17:19.477Z",
  "pubdate": "2026-08-24T20:17:19.477Z",
  "executiveSummary": "An input validation vulnerability exists in Netty's MqttEncoder component prior to versions 4.1.137.Final and 4.2.17.Final. The vulnerability allows prohibited null bytes within MQTT UTF-8 string fields because the encoder fails to properly validate client identifiers, will topics, usernames, and PUBLISH topic names prior to the encoding process.\nThe primary impact of this flaw involves downstream brokers misinterpreting routing rules, access-control lists, and client identities due to string truncation or parsing discrepancies caused by injected null bytes. This introduces significant risk regarding authorization bypass and message misrouting in distributed messaging architectures.\nAttackers capable of supplying user-controlled input to applications utilizing Netty's MQTT encoder can exploit this vulnerability. Successful exploitation requires the targeted application to construct MQTT messages using unvalidated external data, which is then processed and forwarded to compliant or non-compliant MQTT brokers.\nRisk implications include compromised message confidentiality and integrity, unauthorized topic access, and potential identity spoofing within the messaging broker infrastructure. Organizations utilizing vulnerable Netty versions to build or proxy MQTT packets must remediate the issue promptly.",
  "technicalDetails": "The root cause of the vulnerability resides in the MqttEncoder component of the Netty framework, which handles the serialization of MQTT protocol messages. Specifically, the encoder lacks proper validation mechanisms for MQTT UTF-8 string fields, omitting checks for prohibited null bytes (0x00) within critical fields such as client identifiers, will topics, usernames, and PUBLISH topic names.\nThe vulnerable component is MqttEncoder within Netty versions prior to 4.1.137.Final and 4.2.17.Final. The vulnerability manifests when an application accepts untrusted, user-controlled input and passes it directly into Netty's MQTT message construction APIs without enforcing strict structural or syntactic validation of UTF-8 strings according to the MQTT specification.\nThe attack flow proceeds as follows: an attacker crafts malicious input containing embedded null bytes within strings intended for fields like client identifiers, will topics, usernames, or PUBLISH topic names. The client application passes this raw or partially validated input into Netty's MqttEncoder. The encoder serializes the payload without sanitizing or rejecting the null bytes, generating a malformed MQTT control packet.\nWhen the encoded packet reaches downstream MQTT brokers or consuming applications, parsing discrepancies occur. Many parsers process UTF-8 strings using null-termination logic or string-splitting conventions inherited from C-style string handling. Consequently, the downstream broker may truncate the string at the first null byte, leading to routing anomalies, bypassing of access-control lists that evaluate the full string, or identity mismatches where the broker perceives a different client identifier or username than intended.\nNetwork exposure depends on the architecture of the application utilizing Netty, typically encompassing network-accessible endpoints exposed via MQTT or proxy interfaces. Authentication and privilege requirements vary based on the specific application logic; however, the attacker generally requires the ability to supply input that is subsequently encoded into an MQTT message."
}