Description

Contiki-NG's MQTT client parse_publish_vhdr() in os/net/app-layer/mqtt/mqtt.c sets topic_len_received=1 before checking topic_len against the 64-byte limit, so an over-length topic returns early but leaves the flag set. On the next TCP segment, tcp_input() re-invokes the parser with topic_received==0, and the persisted topic_len_received==1 skips the length-reading block containing the guard, falling through directly to a memcpy() that uses the unvalidated 16-bit topic_len as the copy length. The 65-byte topic[] destination overruns into adjacent struct fields including the payload_chunk pointer, which subsequent MQTT code dereferences, giving a compromised or attacker-controlled broker an arbitrary-pointer-write primitive. Contiki-NG's MQTT implementation has no TLS support so the connection is plaintext. Impact ranges from information disclosure and denial of service to remote code execution on embedded targets without memory protection.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-06T22:18:10.900Z",
  "pubdate": "2026-08-06T22:18:10.900Z",
  "executiveSummary": "A state desynchronization and heap-based buffer overflow vulnerability exists in the MQTT client implementation of Contiki-NG, specifically within the parse_publish_vhdr() function located in os/net/app-layer/mqtt/mqtt.c.\nThe vulnerability arises from improper state management when handling malformed MQTT PUBLISH variable headers exceeding predefined length limits.\nThe impact of successful exploitation ranges from denial of service and information disclosure to remote code execution on resource-constrained embedded targets that typically lack memory protection units or address space layout randomization.\nAn unauthenticated attacker controlling a malicious or compromised MQTT broker can exploit this vulnerability over plaintext TCP connections, given that Contiki-NG's MQTT implementation lacks TLS support.\nThe attacker is capable of achieving an arbitrary-pointer-write primitive by forcing a heap-based buffer overrun that corrupts adjacent critical data structures, such as the payload_chunk pointer, which is subsequently dereferenced during normal protocol execution.\nThe risk implications are severe for Internet of Things deployments utilizing Contiki-NG, as compromised nodes can be completely taken over by remote malicious entities communicating over the network.",
  "technicalDetails": "The vulnerability resides in the parse_publish_vhdr() function within os/net/app-layer/mqtt/mqtt.c in Contiki-NG.\nThe root cause of the vulnerability is flawed state persistence combined with inadequate bounds checking.\nDuring the parsing of an MQTT PUBLISH variable header, the function sets the internal state flag topic_len_received=1 prior to validating the topic_len against the designated 64-byte limit.\nWhen an over-length topic is processed, the function returns early, but erroneously leaves the topic_len_received flag set in the parser state context.\nUpon the arrival of the next TCP segment, tcp_input() re-invokes the packet parser.\nAlthough the local variable topic_received is initialized to 0, the parser context retains the persistently set topic_len_received=1 flag from the previous iteration.\nThis leftover state causes the parser to bypass the entire length-reading block containing the crucial safety guard.\nExecution falls through directly to a memcpy() operation that utilizes the unvalidated, attacker-controlled 16-bit topic_len as the copy length parameter.\nThe oversized topic data overflows the fixed 65-byte topic[] destination buffer, resulting in a heap-based buffer overflow.\nThe overflow writes past the boundaries of the intended buffer and corrupts adjacent struct fields in memory.\nCrucially, this corruption overwrites the payload_chunk pointer within the adjacent structure memory.\nSubsequent MQTT handling routines dereference this corrupted payload_chunk pointer, granting the attacker an arbitrary-pointer-write primitive.\nThe exploitation vector requires a network-exposed MQTT client connecting to a malicious or compromised MQTT broker.\nBecause Contiki-NG's MQTT implementation does not support TLS, all network traffic is transmitted in plaintext, allowing potential adversaries to perform man-in-the-middle attacks or operate malicious brokers directly.\nNo authentication or elevated privileges are required by the client against the broker beyond establishing the standard MQTT connection flow where the broker transmits the maliciously crafted PUBLISH packet."
}