CVE-2026-10849: bounds in zephyrproject zephyr
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.
AI Analysis
Technical Summary
The hawkBit client in Zephyr accumulates HTTP response bodies into a heap buffer sized exactly to the received body length but without reserving space for a terminating NUL byte. When the full response is received, the code writes a NUL terminator one byte past the allocated buffer, causing a heap-based out-of-bounds write (CWE-122/CWE-787). The response length is controlled by the remote hawkBit server, making this remotely triggerable. The out-of-bounds write corrupts heap allocator metadata or adjacent allocations, leading to heap corruption and denial of service. The vulnerability is present in Zephyr versions from 2.4.0 up to but not including 4.5.0. The fix adjusts buffer allocation to body length plus one and copies data with memcpy to ensure the terminator is within bounds.
Potential Impact
This vulnerability allows a remote, unauthenticated attacker controlling the hawkBit update server to cause a heap-based out-of-bounds write in the Zephyr client. The single-byte write beyond the allocated buffer corrupts heap metadata or adjacent allocations, which can lead to denial of service through application crashes or faults during subsequent heap operations. There is no direct confidentiality or integrity impact reported, but the denial of service impact is rated high severity.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix involves resizing the buffer to the body length plus one and copying the response body with memcpy to ensure the terminating NUL byte is within the allocated buffer. Until an official patch is available, users should consider restricting or validating update server responses or deploying network controls to prevent malicious or compromised update servers from sending crafted responses.
CVE-2026-10849: bounds in zephyrproject zephyr
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.
CVSS v3.1
Score 8.2high
Affected software
zephyrproject
zephyr
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The hawkBit client in Zephyr accumulates HTTP response bodies into a heap buffer sized exactly to the received body length but without reserving space for a terminating NUL byte. When the full response is received, the code writes a NUL terminator one byte past the allocated buffer, causing a heap-based out-of-bounds write (CWE-122/CWE-787). The response length is controlled by the remote hawkBit server, making this remotely triggerable. The out-of-bounds write corrupts heap allocator metadata or adjacent allocations, leading to heap corruption and denial of service. The vulnerability is present in Zephyr versions from 2.4.0 up to but not including 4.5.0. The fix adjusts buffer allocation to body length plus one and copies data with memcpy to ensure the terminator is within bounds.
Potential Impact
This vulnerability allows a remote, unauthenticated attacker controlling the hawkBit update server to cause a heap-based out-of-bounds write in the Zephyr client. The single-byte write beyond the allocated buffer corrupts heap metadata or adjacent allocations, which can lead to denial of service through application crashes or faults during subsequent heap operations. There is no direct confidentiality or integrity impact reported, but the denial of service impact is rated high severity.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The described fix involves resizing the buffer to the body length plus one and copying the response body with memcpy to ensure the terminating NUL byte is within the allocated buffer. Until an official patch is available, users should consider restricting or validating update server responses or deploying network controls to prevent malicious or compromised update servers from sending crafted responses.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- zephyr
- Date Reserved
- 2026-06-04T12:16:36.322Z
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 6a710cc4bf32cb7a34490860
Added to database: 08/03/2026, 21:48:52 UTC
Last enriched: 08/11/2026, 18:06:38 UTC
Last updated: 09/17/2026, 22:01:32 UTC
Views: 55
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.