CVE-2026-10849: hawkBit Client Heap Overflow Vulnerability

CVE-2026-10849 Overview

CVE-2026-10849 is a heap-based out-of-bounds write [CWE-122] in the hawkBit device management client shipped with Zephyr RTOS. The flaw resides in response_json_cb() inside subsys/mgmt/hawkbit/hawkbit.c. The client allocates a heap buffer sized to the received HTTP response body but reserves no byte for the terminating NUL. When the accumulated body length equals the allocation, the terminator writes one byte past the end of the heap object. A malicious, compromised, or man-in-the-middle hawkBit update server controls the response length and can trigger the write remotely.

Critical Impact
A hostile update server can deterministically corrupt heap metadata on the target device, producing denial of service and, within allocator-dependent bounds, potential further memory corruption.

Affected Products

Zephyr RTOS subsys/mgmt/hawkbit client (pre-patch)
Zephyr v4.0.0 and later where reallocation is sized to exactly downloaded_size + body_len
Zephyr versions before v4.0.0 using the doubling growth strategy when body length equals the current allocation (default 1100 bytes)

Discovery Timeline

2026-08-03 - CVE-2026-10849 published to NVD
2026-08-06 - Last updated in NVD database

Technical Details for CVE-2026-10849

Vulnerability Analysis

The response_json_cb() callback accumulates HTTP response fragments into a heap buffer tracked by hb_context->response_data. When the transfer completes, the code writes response_data[downloaded_size] = '\0' to NUL-terminate the accumulated body. The allocation, however, is sized only to hold the body bytes themselves. Any response body whose length exactly equals the current allocation drives the terminator one byte past the buffer.

The body length and fragmentation values come from rsp->body_frag_start and rsp->body_frag_len, which the remote hawkBit server controls. HTTP length-mismatch validation does not catch the condition because the declared and received lengths agree. TLS, when enabled, authenticates the transport but does not protect the client against a hostile server.

Root Cause

The buffer growth logic omits the trailing NUL byte from its size calculation. Since Zephyr v4.0.0 the reallocation sets response_data_size = downloaded_size + body_len, so any response body larger than the 1100-byte initial buffer produces a deterministic out-of-bounds write. Before v4.0.0, the doubling growth check (downloaded_size + body_len) > response_buffer_size evaluates false at equality. A response body of exactly 1100 bytes skips reallocation and writes the terminator at response_data[1100] of an 1100-byte object.

Attack Vector

A remote attacker who operates, compromises, or intercepts communication with a hawkBit update server sends a crafted response whose body length matches the allocation trigger. No client-side authentication of response content and no length cap gate the write. The corrupted byte lands on adjacent allocator metadata or the next heap allocation, producing a fault on a subsequent malloc or free.

		body_data = rsp->body_frag_start;
		body_len = rsp->body_frag_len;

-		if ((hb_context->dl.downloaded_size + body_len) > hb_context->response_data_size) {
-			hb_context->response_data_size = hb_context->dl.downloaded_size + body_len;
+		if ((hb_context->dl.downloaded_size + body_len + 1) >
+		    hb_context->response_data_size) {
+			hb_context->response_data_size =
+				hb_context->dl.downloaded_size + body_len + 1;
			rsp_tmp = k_realloc(hb_context->response_data,
					    hb_context->response_data_size);
			if (rsp_tmp == NULL) {

Source: Zephyr commit 59d7ab58. The patch adds + 1 to both the sizing comparison and the reallocation length so the terminator always lands within the allocation.

Detection Methods for CVE-2026-10849

Indicators of Compromise

Unexpected device restarts or kernel faults on Zephyr endpoints running the hawkBit client shortly after a firmware polling cycle
hawkBit HTTP responses to embedded clients whose Content-Length equals 1100 bytes or matches the current response_data_size boundary
Update server responses originating from IP addresses or hostnames not matching the provisioned hawkBit endpoint

Detection Strategies

Instrument the hawkBit client build with heap canaries or CONFIG_MEM_SLAB_POINTER_VALIDATE equivalents to trap the single-byte overflow at the point of corruption
Inspect device crash dumps for faults in k_malloc, k_free, or sys_heap routines following a hawkBit polling interval
Log and alert on hawkBit update sessions returning bodies at or above the initial 1100-byte allocation threshold when they originate from unexpected endpoints

Monitoring Recommendations

Capture TLS session metadata for all hawkBit deployments and alert on unexpected certificate rotations or endpoint changes
Aggregate device telemetry from fleet management systems to correlate reboot patterns with update server interactions
Monitor network paths between IoT fleets and their hawkBit servers for evidence of on-path interception or DNS redirection

How to Mitigate CVE-2026-10849

Immediate Actions Required

Rebuild and reflash affected devices with a Zephyr tree that includes commit 59d7ab58d853489e6134081cadb11733730264ac
Pin the hawkBit update server to a hardened, authenticated endpoint and disable fallback to unverified hosts
Audit device fleets to inventory Zephyr images using subsys/mgmt/hawkbit and prioritize update campaigns

Patch Information

The fix sizes the response buffer to body_len + 1 and preserves room for the NUL terminator. Review the GitHub Security Advisory GHSA-39h3-7phx-pwhv for advisory details and the upstream commit for the code change. Vendors shipping Zephyr-based firmware should rebase to a patched release and issue signed firmware updates through their existing OTA channels.

Workarounds

Enforce TLS with mutual authentication so devices only accept responses from a known hawkBit server key
Deploy network segmentation and egress filtering to restrict hawkBit client traffic to trusted management infrastructure
Where updates are infrequent, disable CONFIG_HAWKBIT and manage firmware distribution through an alternate channel until patched images are deployed

bash

# Verify the patched commit is present in the Zephyr source tree
cd zephyr
git log --oneline subsys/mgmt/hawkbit/hawkbit.c | grep 59d7ab58

# Rebuild firmware for the target board after applying the fix
west build -b <board> samples/subsys/mgmt/hawkbit -p always