Cyber Resilience

CVE-2026-10849

Memory Safety in Zephyrproject Zephyr 2.4.0 – 4.5.0

Public PoCMemory Safety
Published
03 August 2026
Modified
09 August 2026
Patch / advisory
CVSS Score v3.1 8.2
Click a component to see what it means
Raw vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H
EPSS Score 0.0028 20th percentile
Risk Priority 60 floored blend · peak EPSS

Summary

CVE-2026-10849 is a high-severity Heap-based Buffer Overflow (CWE-122) vulnerability in Zephyrproject Zephyr. Its CVSS base score is 8.2 (High).

Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 20th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

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…

more

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.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1068 Exploitation for Privilege Escalation Privilege Escalation
Adversaries may exploit software vulnerabilities in an attempt to elevate privileges.
T1190 Exploit Public-Facing Application Initial Access
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network.
T1203 Exploitation for Client Execution Execution
Adversaries may exploit software vulnerabilities in client applications to execute code.
T1210 Exploitation of Remote Services Lateral Movement
Adversaries may exploit remote services to gain unauthorized access to internal systems once inside of a network.
T1211 Exploitation for Stealth Stealth
Adversaries may exploit vulnerabilities to evade detection by hiding activity, suppressing logging, or operating within trusted or unmonitored components.
T1212 Exploitation for Credential Access Credential Access
Adversaries may exploit software vulnerabilities in an attempt to collect credentials.
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2024-6444Same product: Zephyrproject Zephyr
CVE-2024-8798Same product: Zephyrproject Zephyr
CVE-2024-6259Same product: Zephyrproject Zephyr
CVE-2023-5779Same product: Zephyrproject Zephyr
CVE-2023-6749Same product: Zephyrproject Zephyr
CVE-2023-5055Same product: Zephyrproject Zephyr
CVE-2023-1901Same product: Zephyrproject Zephyr
CVE-2023-3725Same product: Zephyrproject Zephyr
CVE-2024-6258Same product: Zephyrproject Zephyr
CVE-2023-4264Same product: Zephyrproject Zephyr

Affected Assets

zephyrproject
zephyr
2.4.0 — 4.5.0

Mitigating Controls

Control response

Prevent
Stop it (NIST 800-53)

Detect
Catch it (NIST detect / respond)

Harden
Shrink the surface (DISA STIG)

Validate
Prove the fix (OWASP ASVS)
  • V1.4.1

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation (including fuzzing and memory-error detectors) can discover heap overflows after they have been coded.

Input validation enforces bounds checking on data written to heap buffers, directly stopping the overflow condition from being introduced.

Requiring documented secure-development standards and tools can mandate bounds-checked coding practices that avoid the weakness.

Security engineering principles require use of memory-safe constructs and bounds-checked allocation routines that avoid introducing heap overflows.

Memory-protection mechanisms limit the ability of a heap overflow to execute attacker-controlled code or corrupt adjacent structures.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

PR.PS-06 full match
prevents

Secure-development practices directly require bounds checking and safe memory handling that prevent heap overflows.

ID.RA-01 partial match
prevents

Vulnerability scanning and recording can discover heap-overflow flaws but does not prevent their introduction in code.

PR.PS-02 partial match
prevents

Timely patching removes known heap-overflow instances after they exist.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

finds

Security testing in development and acceptance can detect heap overflows before release.

prevents

Secure development lifecycle mandates practices that reduce the likelihood of introducing heap overflows.

prevents

Application security requirements can specify bounds-checking and safe memory APIs that mitigate heap overflows.

prevents

Secure architecture and engineering principles include memory-safety and input-validation controls that address heap overflows.

prevents

Secure coding standards directly prescribe techniques (safe functions, bounds checks) that prevent heap-based buffer overflows.

prevents

Change management can enforce review gates that catch unsafe memory operations before deployment.

References