~ / search / GHSA-6ghj-frrj-jjj3

GHSA-6ghj-frrj-jjj3

Netty has Unbounded Direct Memory Consumption in its RedisDecoder

Source: GitHub Advisory Database (reviewed) High CVE-2026-44890

Packages

EcosystemPackageAffectedFixed in
Maven io.netty:netty-codec-redis >= 4.2.0.Final, < 4.2.15.Final 4.2.15.Final
Maven io.netty:netty-codec-redis < 4.1.135.Final 4.1.135.Final

Details

As written in the advisory (Markdown source, shown as plain text).

### Summary An attacker can cause DoS by sending crafted Redis payloads across multiple connections without `\r\n`. This exhausts the server's direct memory pool (OutOfDirectMemoryError), preventing legitimate connections from being processed. ### Details io.netty.handler.codec.redis.RedisDecoder decodes the length of bulk strings and array headers using the `decodeLength` method. This method reads bytes from the network until it encounters a `\n` character. However, it does not enforce any maximum length check while buffering the bytes if the `\n` character is not found. An attacker can exploit this by sending a continuous stream of digits (e.g., `$1111...`) without ever sending a `\n`. To cause a true Denial of Service, an attacker must open multiple concurrent connections and distribute the unbounded payloads among them. According to the RESP specification (https://redis.io/docs/latest/develop/reference/protocol-spec/), all parts of the protocol are strictly terminated with `\r\n`. Furthermore, the length prefix itself is an integer representation that must fit within standard numeric limits (e.g., a 64-bit signed integer). Therefore, a stream of digits exceeding these bounds without `\r\n` is a protocol violation and should be rejected immediately rather than buffered indefinitely. ### Impact Denial of Service due to memory exhaustion. Any application using Netty's RedisDecoder to handle untrusted Redis traffic is vulnerable.

References

External links from the advisory. They lead to third-party sites.