CVE-2026-10849
PoC nicheHeap Out-of-Bounds Write in Zephyr RTOS hawkBit Update Client
Zephyr RTOS's hawkBit device management client (subsys/mgmt/hawkbit/hawkbit.c) accumulates the HTTP response body into a heap buffer that reserves no room for a terminating NUL, so when the accumulated body length equals the allocation the terminator is written one byte past the end of the heap object (CWE-122/CWE-787). Since v4.0.0 any response body larger than the 1100-byte initial buffer triggers the out-of-bounds write deterministically, while pre-v4.0.0 builds are affected when the body length exactly equals the current allocation (1100 bytes by default); both cases are remotely reachable because the body length is fully controlled by the update server, and TLS does not protect against a hostile or man-in-the-middle server. An attacker controlling the update-server path gains a fixed one-byte NUL heap corruption that typically causes denial of service (a fault on a subsequent allocation or free), with bounded, allocator-dependent potential for further corruption. Only Zephyr-based devices built with the hawkBit update client enabled and configured against a remote update server are affected. The flaw is documented in a public Zephyr security advisory (GHSA-39h3-7phx-pwhv), but it is not in CISA KEV, has a low 0.3% EPSS (26th percentile), and there is no evidence of in-the-wild exploitation.
What to do: Upgrade Zephyr to the patched release identified in the advisory GHSA-39h3-7phx-pwhv, which sizes the buffer to body length plus one and copies with memcpy so the terminator always lands inside the allocation. Until patched, confirm whether your builds actually enable the hawkBit subsystem (builds without it are unaffected) and harden the update-server path with TLS certificate pinning to prevent man-in-the-middle triggers, noting that TLS alone does not protect against a compromised or hostile hawkBit server. Because the impact is denial of service, prioritize devices where availability is critical.
| Zephyr Project Zephyr RTOS (hawkBit device management client, subsys/mgmt/hawkbit) | All versions with the hawkBit client enabled, spanning both the pre-v4.0.0 line (trigger: response body length exactly equal to the current allocation, 1100 byt |
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
The hawkBit device management client in subsys/mgmt/hawkbit accumulates the body of an HTTP response from the update server into a heap buffer in response_json_cb() (subsys/mgmt/hawkbit/hawkbit.c). The buffer is sized to hold the received body bytes but reserves no space for a terminating NUL. When the full response has arrived, the code writes response_data[downloaded_size] = '\0' — and whenever the accumulated body length equals the allocation, that terminator lands one byte past the end of the heap object (a heap-based out-of-bounds write, CWE-122 / CWE-787). The body length and fragmentation are taken directly from the parsed HTTP response (rsp->body_frag_start / rsp->body_frag_len) and are fully controlled by the remote hawkBit server, which chooses its own response length. The precise trigger depends on how the buffer grows, and both forms are remotely reachable. Since v4.0.0 the reallocation is sized to exactly downloaded_size + body_len, so any response body larger than the 1100-byte initial buffer makes the out-of-bounds write deterministic; such response sizes are normal for hawkBit deployment metadata. Before v4.0.0 the buffer grew by doubling and the growth check ((downloaded_size + body_len) > response_buffer_size) is false at equality, so a response body whose length is exactly the current allocation — 1100 bytes with the default initial buffer — skips the reallocation entirely and writes the terminator at response_data[1100] of an 1100-byte object. The HTTP length-mismatch check does not catch this, because the declared and received lengths genuinely agree. Either form is reachable by a malicious, compromised, or man-in-the-middle update server (TLS is optional and, when enabled, does not protect against a hostile server), with no authentication of response content and no client-side length cap protecting the write. The out-of-bounds write is a fixed single NUL byte immediately following the allocation, corrupting adjacent allocator metadata or the next allocation. The practical impact is heap corruption leading to denial of service (fault on a subsequent allocation or free), with the bounded, allocator-dependent possibility of further corruption. The fix sizes the buffer to the body length plus one and copies with memcpy, ensuring the terminator always lands within the allocation.
- Vendors
- zephyrproject
- Products
- zephyr
- Weakness
- CWE-122, CWE-787
- Vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
In the news0 stories
No ingested article mentions this CVE yet.