Description
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.
Published: 2026-08-03
Score: 8.2 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The hawkBit client in Zephyr incorrectly sizes the buffer that accumulates an HTTP response body, omitting space for the terminating NUL byte. When the accumulated length equals the allocation, the code writes a NUL one byte beyond the allocated heap object, triggering a heap-based out‑of‑bounds write (CWE‑122 / CWE‑787). The overflow corrupts adjacent allocator metadata or the next heap allocation, producing a denial of service by causing a fault on subsequent allocations or frees, with a bounded possibility of further system corruption.

Affected Systems

Zephyr Project Zephyr devices running any version before 4.0.0 are affected. Version 4.0.0 introduces a reallocation logic that allocates the body length plus one byte, thereby preventing the out-of-bounds write.

Risk and Exploitability

The CVSS score of 8.2 indicates high severity. The EPSS score is not available, but the vulnerability is remotely reachable via the hawkBit update server, which can be compromised or act as a man-in-the-middle. TLS is optional and does not protect an attacker from manipulating the response body length because no client-side size cap or response authentication exists. The practical impact is a deterministic denial of service when a response body larger than the initial 1100‑byte buffer is received; the variant where the body length equals the buffer also leads to corruption. The vulnerability is not listed in CISA KEV at this time.

Generated by OpenCVE AI on August 4, 2026 at 09:41 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade Zephyr to the 4.0.0 release or later, which implements the fixed buffer allocation logic.
  • Configure the hawkBit client to use TLS and verify the server’s certificate to prevent a malicious or compromised update server from supplying oversized responses.
  • Add an additional client-side check to reject or truncate HTTP response bodies that exceed a safe threshold if the firmware cannot be updated to a patched version.

Generated by OpenCVE AI on August 4, 2026 at 09:41 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 04 Aug 2026 20:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Mon, 03 Aug 2026 23:15:00 +0000

Type Values Removed Values Added
First Time appeared Zephyrproject
Zephyrproject zephyr
Vendors & Products Zephyrproject
Zephyrproject zephyr

Mon, 03 Aug 2026 21:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Heap out-of-bounds write in Zephyr hawkBit OTA client when terminating server response body
Weaknesses CWE-122
CWE-787
References
Metrics cvssV3_1

{'score': 8.2, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H'}

Subscriptions

Zephyrproject Zephyr
cve-icon MITRE

Status: PUBLISHED

Assigner: zephyr

Published:

Updated: 2026-08-04T19:29:56.573Z

Reserved: 2026-06-04T12:16:36.322Z

Link: CVE-2026-10849

cve-icon Vulnrichment

Updated: 2026-08-04T19:29:39.850Z

cve-icon NVD

Status : Analyzed

Published: 2026-08-03T22:16:47.963

Modified: 2026-08-09T14:41:25.130

Link: CVE-2026-10849

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-04T09:45:03Z

Weaknesses