Loading story…
Contiki-NG disclosed and patched CVE-2026-5857, a high-severity memory corruption flaw in its MQTT client that can be triggered by a malicious or compromised broker. The bug resides in parse_publish_vhdr() and stems from parser state being preserved across TCP segments: topic_len_received can be set before the incoming topic length is validated against the 64-byte limit, allowing a later segment to bypass the check and reach a memcpy() with an unvalidated 16-bit length. That can overflow the 65-byte topic buffer, corrupt adjacent fields such as payload_chunk, and potentially create an arbitrary-pointer-write condition that could lead to information disclosure, denial of service, or possible remote code execution on embedded devices lacking memory protection.
The fix was merged through pull request #3163 in commit a34a2dbdc8bea784bd2ae5079aa4be520cd74f2d, which broadly hardens Contiki-NG's MQTT TCP input parsing. In addition to blocking oversized PUBLISH topic lengths, the update adds stricter validation for MQTT v5 property lengths, safer payload-copying logic, improved handling of partial fields split across TCP segments, and protections for multiple MQTT packets coalesced into a single segment. The patched code now aborts connections on malformed input and addresses related parser issues including integer underflow, out-of-bounds reads, malformed length handling, incorrect Variable Byte Integer decoding, and state corruption across packet boundaries.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
On August 6, 2026, CVE-2026-5857 was published for an out-of-bounds write in Contiki-NG's MQTT client parse_publish_vhdr() logic. The CVE states versions earlier than commit a34a2db are affected and references the fixing commit and pull request #3163.
On July 10, 2026, Contiki-NG merged commit a34a2db into the develop/v5.2 branch via pull request #3163. The patch hardened MQTT TCP input parsing against malformed and coalesced packets, added stricter bounds checks, and aborts connections on malformed input.
On June 22, 2026, Contiki-NG added pull request #3163 with security-relevant fixes for MQTT input parsing, including checks for malformed PUBLISH topic lengths, MQTT v5 property-length handling, Variable Byte Integer decoding, and TCP-segment boundary parsing issues.
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.
3 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
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 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
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.
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