Loading story…
Netty released versions 4.2.17.Final and 4.1.137.Final with security hardening and vulnerability fixes across its HTTP, SCTP, compression, TLS, MQTT, and SOCKS components. The most prominent issue, tracked as CVE-2026-59903, affects io.netty.handler.codec.http.cors.CorsHandler, which overwrote existing Vary headers with Vary: Origin. That behavior could strip cache-partitioning headers such as Authorization or Cookie, enabling cache poisoning and exposing authenticated content through shared proxies, reverse proxies, or CDNs. The fix preserves existing Vary semantics by appending Origin only when needed.
The releases also address CVE-2026-59902 in SctpMessageCompletionHandler, where fragmented SCTP messages could consume excessive heap or direct memory because buffered bytes were not fully capped, creating a denial-of-service risk. Netty added a maxBufferedBytes ceiling with a default limit of 16 MB and bundled additional hardening, including stricter validation for malformed MQTT and SOCKS inputs, safer TLS ClientHello parsing, trust manager compatibility checks, safer decompression in Lz4FrameDecoder, protection against invalid Snappy chunk lengths, and fixes for buffer, memory, and classloader leaks.
See affected versions and whether adversaries are exploiting it.
6 events from the most recent confirmed update back to the earliest known activity.
Netty released 4.1.137.Final as a backport release containing security-relevant fixes including AsciiString sanitization, Snappy and LZ4 decompression hardening, buffer leak fixes, and the SCTP memory-accounting remediation.
Netty merged commit 1b5abc6 into its 4.2 branch, fixing a CorsHandler Vary-header overwrite issue that could enable cache poisoning and information disclosure, along with MQTT, SOCKS, TLS ClientHello, trust manager, and SCTP buffering hardening changes.
A CVE report described a Netty CorsHandler flaw where existing Vary headers were overwritten with "Vary: Origin," potentially removing cache-partitioning headers like Authorization or Cookie and exposing authenticated content through shared caches. The report identifies 4.1.137.Final and 4.2.17.Final as patched versions.
A CVE report described a denial-of-service issue in Netty's SctpMessageCompletionHandler where fragmented SCTP messages could consume about 1.05 GB per connection under default limits because buffered bytes were not capped. The report states the fix adds a 16 MB maxBufferedBytes ceiling and identifies 4.1.137.Final and 4.2.17.Final as fixed versions.
Netty merged pull request #17217 into its 4.1 branch, bringing in security-relevant fixes for fragmented TLS ClientHello parsing in SslClientHelloHandler, bounded SCTP buffering, CorsHandler Vary-header preservation, and MQTT, SOCKS, and trust-manager validation hardening. The changes were associated with the 4.1.137.Final milestone.
Netty released 4.2.17.Final with 25 commits since 4.2.16.Final, including security-relevant hardening such as safer decompression handling, Snappy decoder protections, leak fixes, and the bundled security fixes from the August 4 merge.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
8 references tracked. Mallory keeps watching after this page renders.
cvereports.com
Open sourcecvereports.com
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.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 released **4.1.135.Final** and **4.2.15.Final** to patch a large batch of security vulnerabilities across core networking components, with fixes spanning `netty-resolver-dns`, `netty-codec-http2`, `netty-handler`, `netty-codec-redis`, `netty-codec-haproxy`, native transports, and SCTP support. The DNS resolver fixes address multiple cache-poisoning paths, including predictable transaction IDs combined with a static UDP source port, missing bailiwick checks for **CNAME** records, and insufficient validation of **NS** records; one of those issues was later tracked as **CVE-2026-45674**. Netty also fixed a TLS flaw in which wrapping a plain `X509TrustManager` could silently disable hostname verification for clients, and an IPv6 access-control bypass in `IpSubnetFilterRule`, later assigned **CVE-2026-44249**.
Aug 20, 2026
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 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