Netty: RedisArrayAggregator max-elements failure leaves retained partial aggregate state
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 4.1.136.Final, 4.2.16.Final
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: poc
- Automatable: yes
- Technical impact: partial
Summary
Netty is an asynchronous, event-driven network application framework. Prior to 4.1.136.Final and 4.2.16.Final, the RedisArrayAggregator Redis codec clears retained partial aggregate state when the maxNestedArrayDepth limit is exceeded, but it does not clear the same state when the sibling maxElements limit is exceeded. A peer can start a valid RESP array, send a bulk string child, then send a nested array header longer than the configured maxElements. Netty throws a decoder exception in decodeRedisArrayHeader, but the existing partial aggregate remains retained in the handler. If the application leaves the channel alive after the exception, later messages are still consumed into the pre-error aggregate, allowing an unauthenticated peer to keep attacker-controlled aggregate state alive across a security-limit exception and pin retained pooled buffers. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: poc · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- netty netty
fixed in 4.1.136.Final; From 4.2.0-Final · fixed in 4.2.16.Final
- io.netty:netty-codec-redisMaven
fixed in 4.1.136.Final
- io.netty:netty-codec-redisMaven
From 4.2.0-Final · fixed in 4.2.16.Final