EUVD-2026-54226
GHSA-x5g5-4jq8-vj28
Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable via a malicious broker or plaintext MITM (AV:N) with no client authentication (PR:N), but the multi-segment state trick raises complexity (AC:H); memory-corruption-to-RCE gives high C/I/A, scope unchanged.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
3DescriptionCVE.org
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_received0, and the persisted topic_len_received1 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.
AnalysisAI
Out-of-bounds write in the Contiki-NG MQTT client (os/net/app-layer/mqtt/mqtt.c) lets a malicious or compromised MQTT broker overflow a 65-byte topic[] buffer and corrupt the adjacent payload_chunk pointer, producing an arbitrary-pointer-write primitive that can escalate to remote code execution on embedded targets lacking memory protection. The flaw stems from parse_publish_vhdr() setting topic_len_received=1 before enforcing the 64-byte topic length limit, so an over-length topic split across TCP segments bypasses the guard on parser re-entry and reaches a memcpy() that trusts the unvalidated 16-bit topic_len. Because the stack has no TLS, the plaintext channel also exposes devices to network man-in-the-middle injection; there is no public exploit identified at time of analysis and it is not in CISA KEV.
Technical ContextAI
Contiki-NG is an open-source operating system for resource-constrained IoT and embedded devices (successor to Contiki), and the affected component is its application-layer MQTT client. The bug is a CWE-787 out-of-bounds write driven by a stateful TCP-stream parser: MQTT PUBLISH variable headers can arrive fragmented across TCP segments, so parse_publish_vhdr() carries cross-invocation state via flags such as topic_len_received. The root cause is a validation-ordering error - the received flag is set before the topic_len bounds check, so when tcp_input() re-invokes the parser on the next segment with topic_received0 but topic_len_received1, execution skips the entire length-reading block (and its guard) and falls straight into the memcpy() using the attacker-supplied 16-bit topic_len as the copy length, overrunning the 65-byte topic[] into adjacent struct fields. The upstream fix (commit a34a2dbdc8, PR #3163) reworks the state machine (adds topic_len_msb_received), validates topic_len against both remaining_length and MQTT_MAX_TOPIC_LENGTH before copying, aborts the connection on violation, and additionally hardens variable-byte-integer decoding and cross-packet payload bounding.
RemediationAI
Upstream fix available (PR/commit); released patched version not independently confirmed - apply Contiki-NG commit a34a2dbdc8bea784bd2ae5079aa4be520cd74f2d (PR https://github.com/contiki-ng/contiki-ng/pull/3163), which validates topic_len against remaining_length and MQTT_MAX_TOPIC_LENGTH before the memcpy and aborts the connection on violation, then rebuild and reflash affected devices; since no tagged patched release is confirmed, rebuild from a repository state that includes this commit. Where firmware cannot be updated immediately, the most effective compensating controls are: restrict devices to connect only to a trusted, hardened broker and block outbound MQTT (typically TCP 1883) to any other destination, which removes the attacker-controlled-broker path but breaks connectivity to other brokers; and place the plaintext MQTT traffic on an isolated network segment or VPN tunnel to prevent man-in-the-middle injection, at the cost of added network complexity. Because the stack has no TLS, in-transit encryption is not available without external tunneling, and disabling or not compiling the MQTT client entirely eliminates exposure where the feature is unused.
Same weakness CWE-787 – Out-of-bounds Write
View allShare
External POC / Exploit Code
Leaving vuln.today