ZephyrProject Zephyr up to 4.4.x hawkBit hawkbit.c response_json_cb body_frag_start/body_frag_len heap-based overflow

Summaryinfo

A vulnerability was found in ZephyrProject Zephyr up to 4.4.x. It has been declared as critical. Affected is the function response_json_cb of the file subsys/mgmt/hawkbit/hawkbit.c of the component hawkBit. The manipulation of the argument body_frag_start/body_frag_len results in heap-based overflow. This vulnerability is reported as CVE-2026-10849. The attack can be launched remotely. No exploit exists.

Detailsinfo

A vulnerability was found in ZephyrProject Zephyr up to 4.4.x. It has been classified as critical. Affected is the function response_json_cb of the file subsys/mgmt/hawkbit/hawkbit.c of the component hawkBit. The manipulation of the argument body_frag_start/body_frag_len with an unknown input leads to a heap-based overflow vulnerability. CWE is classifying the issue as CWE-122. A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). This is going to have an impact on integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at github.com. This vulnerability is traded as CVE-2026-10849 since 06/04/2026. The exploitability is told to be easy. It is possible to launch the attack remotely. The exploitation doesn't require any form of authentication. There are known technical details, but no exploit is available.

Upgrading to version 4.5.0 eliminates this vulnerability. Applying the patch 59d7ab58d853489e6134081cadb11733730264ac is able to eliminate this problem.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Project Management Software

Vendor

• ZephyrProject

Name

• Zephyr

Version

• 4.0
• 4.1
• 4.2
• 4.3
• 4.4

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion