Loading story…
Netty merged fixes to limit memory allocation in its Brotli and Zstandard HTTP decompression paths after identifying denial-of-service risks from attacker-controlled compressed input. One change passes HttpContentDecompressor's maxAllocation setting to BrotliDecoder and ZstdDecoder, bringing them in line with gzip and zlib handling and reducing exposure to zip-bomb-style memory exhaustion in constrained environments. A second change adds a maxWindowLog parameter to ZstdDecoder so oversized Zstandard frames can be rejected before large native-memory allocations occur.
The Zstandard issue stemmed from libzstd allocating memory based on a frame's declared window size before decoding, allowing a small malicious frame to force large per-stream allocations and potentially crash servers. Netty set DEFAULT_MAX_WINDOW_LOG = 27, validated configurable values in the range 10 to 31, merged the changes into the 4.2 branch, and ported them to 4.1 and 5.0. The protections shipped in Netty 4.2.15.Final, alongside other security fixes, and downstream projects including Apache Spark and ArcadeDB moved to upgrade to consume the release.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
2 events from the most recent confirmed update back to the earliest known activity.
Netty merged pull request #16850 into the 4.2 branch to add a maxWindowLog parameter to ZstdDecoder, limiting attacker-controlled Zstandard window sizes that could otherwise trigger excessive native memory allocation and out-of-memory conditions.
Netty merged pull request #16844 to pass HttpContentDecompressor's maxAllocation setting to BrotliDecoder and ZstdDecoder, aligning them with gzip and zlib to reduce zip-bomb-style memory exhaustion risk.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
3 references tracked. Mallory keeps watching after this page renders.
github.com
Open sourcegithub.com
Open sourceredirect.github.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Netty published a broad set of security advisories covering **22 vulnerabilities** across its networking stack, with impacts ranging from remote denial of service to trust-boundary failures. The issues affect multiple modules and protocols, including **HTTP/2, HTTP/3, QUIC, DNS, Redis, SCTP, Unix domain sockets, HAProxy PROXY protocol v2, and TLS handling**. Reported consequences include uncontrolled memory allocation, `ByteBuf` and file descriptor leaks, failure to enforce HTTP/2 stream limits, DNS cache poisoning, improper TLS hostname validation, IPv6 subnet access-control bypass, request smuggling, and QUIC reflection or stateless reset abuse. One of the most serious flaws, **`CVE-2026-45416`**, allows a remote attacker to send as little as **nine bytes** in a crafted TLS `ClientHello` and trigger roughly **16 MiB** of unpooled direct-memory allocation per connection in Netty's SNI handling path. Because the buffer can remain allocated until the connection closes, repeated connections can exhaust direct memory and disrupt services. The flaw affects **Netty 4.1.x before `4.1.135.Final`** and **4.2.0.Final through `4.2.14.Final`**, and was fixed in **`4.1.135.Final`** and **`4.2.15.Final`**; the wider advisory set was published through Netty's GitHub security advisories and highlights the risk to Java applications that embed Netty as a dependency.
Jul 10, 2026
Netty disclosed and fixed **CVE-2026-48059**, a memory leak in its HAProxy PROXY protocol v2 codec that can let remote clients exhaust server memory by sending syntactically valid headers with nested `PP2_TYPE_SSL` TLVs at depth two or greater. The flaw leaves the underlying pooled `ByteBuf` cumulation buffer permanently pinned even though parsing completes successfully and no exception is raised, creating an availability risk rather than a confidentiality or integrity impact. The issue affects Netty releases before `4.1.135.Final` and `4.2.15.Final`, and the project published fixes in those versions alongside a GitHub security advisory. Separately, Netty also merged a non-security correction for `memoryAddress()` handling in wrapped direct `ByteBuffer` paths when `Unsafe` is disabled, shipping that consistency fix in `4.2.14.Final` and auto-porting it to Netty 5.0, but the HAProxy memory-exhaustion bug is addressed in the later `4.2.15.Final` release.
Jun 29, 2026
Netty corrected an MQTT decoder regression introduced during remediation for **`CVE-2026-44248`**, after the library began incorrectly rejecting valid fragmented or batched MQTT packets with **`TooLongFrameException`**. The flaw came from using `readableBytes()` inside a `ReplayingDecoder` path, where the value reflected the cumulation buffer or an effectively unbounded readable size instead of the current packet’s declared remaining length during variable-header replay handling. The project fixed the logic in pull request **#16787** by basing the size check on **`bytesRemainingBeforeVariableHeader`** and added regression tests covering both valid in-limit packets and oversized packets. The fix was merged into the **4.2** branch for release in **`4.2.14.Final`**, then auto-ported to **4.1** in **#16838** and later re-applied in **#16916** after a subsequent security merge reintroduced the broken code. Netty also addressed a related `ReplayingDecoder` `readableBytes()` issue in **#16813** and auto-port **#16919**, ensuring early replay handling works correctly for incomplete MQTT properties blocks. Downstream projects including **ArcadeDB** and **ThingsBoard** referenced or adopted the updated Netty releases to resolve the decoder behavior.
Jun 29, 2026