CVE-2026-10849

Source
https://cve.org/CVERecord?id=CVE-2026-10849
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-10849.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-10849
Aliases
  • GHSA-39h3-7phx-pwhv
Published
2026-08-03T21:21:32.890Z
Modified
2026-08-08T03:48:17.808150828Z
Severity
  • 8.2 (High) CVSS_V3 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H CVSS Calculator
Summary
Heap out-of-bounds write in Zephyr hawkBit OTA client when terminating server response body
Details

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 responsejsoncb() (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 responsedata[downloadedsize] = '\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->bodyfragstart / rsp->bodyfraglen) 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 downloadedsize + bodylen, 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 ((downloadedsize + bodylen) > responsebuffersize) 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.

Database specific
{
    "cna_assigner": "zephyr",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/10xxx/CVE-2026-10849.json",
    "unresolved_ranges": [
        {
            "extracted_events": [
                {
                    "introduced": "2.4.0"
                },
                {
                    "fixed": "4.5.0"
                }
            ],
            "source": "AFFECTED_FIELD"
        }
    ],
    "cwe_ids": [
        "CWE-122",
        "CWE-787"
    ]
}
References

Affected packages

Git / github.com/zephyrproject-rtos/zephyr

Affected ranges

Type
GIT
Repo
https://github.com/zephyrproject-rtos/zephyr
Events
Introduced
0 Unknown introduced commit / All previous commits are affected
Fixed
Fixed
Database specific
{
    "extracted_events": [
        {
            "introduced": "0"
        },
        {
            "fixed": "v4.0.0"
        }
    ],
    "source": [
        "DESCRIPTION",
        "REFERENCES"
    ]
}

Affected versions

v1.*
v1.0.0
v1.1.0
v1.1.0-rc1
v1.10.0
v1.10.0-rc1
v1.10.0-rc2
v1.10.0-rc3
v1.11.0
v1.11.0-rc1
v1.11.0-rc2
v1.11.0-rc3
v1.12.0
v1.12.0-rc1
v1.12.0-rc2
v1.12.0-rc3
v1.13.0
v1.13.0-rc1
v1.13.0-rc2
v1.13.0-rc3
v1.14.0
v1.14.0-rc1
v1.14.0-rc2
v1.14.0-rc3
v1.2.0
v1.2.0-rc1
v1.2.0-rc2
v1.3.0
v1.3.0-rc1
v1.3.0-rc2
v1.4.0
v1.4.0-rc1
v1.4.0-rc2
v1.4.0-rc3
v1.5.0
v1.5.0-rc0
v1.5.0-rc1
v1.5.0-rc2
v1.5.0-rc3
v1.5.0-rc4
v1.6.99
v1.7.99
v1.8.99
v1.9.0
v1.9.0-rc1
v1.9.0-rc2
v1.9.0-rc3
v1.9.0-rc4
v2.*
v2.0.0
v2.0.0-rc1
v2.0.0-rc2
v2.0.0-rc3
v2.1.0
v2.1.0-rc1
v2.1.0-rc2
v2.1.0-rc3
v2.2.0
v2.2.0-rc1
v2.2.0-rc2
v2.2.0-rc3
v2.3.0
v2.3.0-rc1
v2.3.0-rc2
v2.4.0
v2.4.0-rc1
v2.4.0-rc2
v2.4.0-rc3
v2.5.0
v2.5.0-rc1
v2.5.0-rc2
v2.5.0-rc3
v2.5.0-rc4
v2.6.0
v2.6.0-rc1
v2.6.0-rc2
v2.6.0-rc3
v2.7.0-rc1
v2.7.0-rc2
v2.7.0-rc3
v2.7.99
v3.*
v3.0.0
v3.0.0-rc1
v3.0.0-rc2
v3.0.0-rc3
v3.1.0
v3.1.0-rc1
v3.1.0-rc2
v3.1.0-rc3
v3.2.0
v3.2.0-rc1
v3.2.0-rc2
v3.2.0-rc3
v3.3.0
v3.3.0-rc1
v3.3.0-rc2
v3.3.0-rc3
v3.4.0
v3.4.0-rc1
v3.4.0-rc2
v3.4.0-rc3
v3.5.0
v3.5.0-rc1
v3.5.0-rc2
v3.5.0-rc3
v3.6.0
v3.6.0-rc1
v3.6.0-rc2
v3.6.0-rc3
v3.7.0
v3.7.0-rc1
v3.7.0-rc2
v3.7.0-rc3
v4.*
v4.0.0
v4.0.0-rc1
v4.0.0-rc2
v4.0.0-rc3
v4.1.0
v4.1.0-rc1
v4.1.0-rc2
v4.1.0-rc3
v4.2.0
v4.2.0-rc1
v4.2.0-rc2
v4.2.0-rc3
v4.3.0
v4.3.0-rc1
v4.3.0-rc2
v4.3.0-rc3
v4.4.0
v4.4.0-rc1
v4.4.0-rc2
v4.4.0-rc3
zephyr-v1.*
zephyr-v1.0.0
zephyr-v1.1.0
zephyr-v1.10.0
zephyr-v1.11.0
zephyr-v1.12.0
zephyr-v1.13.0
zephyr-v1.14.0
zephyr-v1.2.0
zephyr-v1.3.0
zephyr-v1.4.0
zephyr-v1.5.0
zephyr-v1.9.0
zephyr-v2.*
zephyr-v2.0.0
zephyr-v2.1.0
zephyr-v2.2.0
zephyr-v2.3.0
zephyr-v2.4.0
zephyr-v2.5.0
zephyr-v2.6.0
zephyr-v3.*
zephyr-v3.0.0
zephyr-v3.1.0
zephyr-v3.2.0
zephyr-v3.3.0
zephyr-v3.4.0
zephyr-v3.5.0

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-10849.json"