Zephyr 4.5.0 came out on October 28, and two days later the project shipped a release for an older branch. Tag v4.3.2 went up on the Zephyr GitHub repository on 30 October 2026 at 20:17, at commit 28af05c. The release notes describe it in one line: "This is a bugfix release for Zephyr 4.3.1."

That line undersells it. Most of the release is a security section, and each entry carries a CVE number and a GitHub Security Advisory (GHSA) ID. The bugs touch USB device classes, the Bluetooth host, networking and TLS, two OTA update clients, LoRaWAN, flash drivers, the kernel, and the userspace syscall verifiers that sit at the boundary between user mode and the kernel. If you have firmware in the field built on the 4.3 branch and you have not moved to 4.4 or 4.5, this is the release that matters to you.

Below, the security list is grouped by subsystem. CVE numbers and descriptions are taken from the release page and from the Zephyr project's vulnerabilities page. The list here is a selection, not the whole set: the release page lists 225 CVE entries, and 104 of them are marked "Under embargo" with no description yet, one of them until 2026-11-02.

Userspace: the syscall verifiers

When Zephyr is built with CONFIG_USERSPACE, each system call has a verification handler (a z_vrfy_* function). Its job is to check the arguments from a user-mode thread before the kernel uses them. In that configuration the handler is the trust boundary. Several 4.3.2 fixes are bugs in these handlers.

  • CVE-2026-9771: missing device-pointer validation in the flash_copy() syscall. The release notes call this a userspace privilege escalation. The handler, z_vrfy_flash_copy() in drivers/flash/flash_util.c, validated only the output buffer. It passed the struct device * arguments src_dev and dst_dev through without object validation. The NIST NVD record for this CVE has the same description and notes that, with CONFIG_USERSPACE enabled, this handler is the kernel-side trust boundary for a user-mode caller.
  • CVE-2026-9728: a time-of-check/time-of-use (TOCTOU) race in the mbox_send syscall verifier that the release notes say allows userspace to leak kernel memory.
  • CVE-2026-12234: a TOCTOU double-fetch in the zsock_sendmsg/recvmsg verifiers that the release notes say allows a kernel-heap out-of-bounds write.

TOCTOU and double-fetch bugs are the same kind of mistake. The verifier reads a value from user memory and checks it. Then the kernel reads the same value again and uses it. A second user thread can change the value between the two reads.

Out-of-bounds writes

The release lists many out-of-bounds (OOB) writes. A selection:

  • CVE-2026-12052: OOB write in the USB CDC NCM control handler when the host wLength is smaller than the response.
  • CVE-2026-8718: OOB write in the DTLS peer Connection ID getsockopt.
  • CVE-2026-10849: heap OOB write in the hawkBit OTA client.
  • CVE-2026-12363: OOB write in LoRaWAN fragmented transport.
  • CVE-2026-6688: OOB write in POSIX readdir() when an entry name exceeds NAME_MAX.
  • CVE-2026-12235: OOB write in Xtensa llext PLT relocation from a malformed ELF.
  • CVE-2026-11743: a missing negative-offset/overflow check in the SF32LB MPI QSPI NOR flash driver that allows out-of-bounds read and write.

The Zephyr vulnerabilities page explains the LoRaWAN bug. frag_transport_package_callback() reads frag_counter = hdr->frag_index_n & 0x3FFF from the downlink payload. The decoder then derives an array index and a flash offset as frag_counter - 1. Fragments are numbered from 1, so a counter of 0 underflows. The page says the value comes from downlink input, and that triggering the bug requires authenticated downlinks (LoRaWAN session keys, or a malicious or compromised network or FUOTA server) and an active fragmentation session. It rates the impact as contained: corruption of decoder state and denial of the firmware-update session rather than controllable code execution. The fix rejects a counter of 0.

The readdir() bug (CVE-2026-6688) is conditional. The Zephyr page says that since dirent.h was reworked in v4.1.0, NAME_MAX falls back to 14 when the C library does not define it, as with CONFIG_MINIMAL_LIBC and some other libc wrappers. A directory entry of 15 or more characters then writes past the static d_name buffer. Builds using picolibc (the default) or newlib define NAME_MAX as 255 and are not affected.

Bluetooth

The release has several Bluetooth CVEs. Two GATT bugs are among them:

  • CVE-2026-10685: use-after-free of GATT subscribe params in the Bluetooth host CCC-write response handler.
  • CVE-2026-12236: an infinite loop in the GATT client's Read-By-Type parsing, triggered by responses with zero data length.

Others in the list include a Bluetooth Mesh solicitation PDU stack buffer overflow (CVE-2026-15894), a NULL-pointer dereference in Bluetooth HAS (CVE-2026-13213), missing channel-state validation in the Bluetooth Classic L2CAP receive path (CVE-2026-15460) and a Bluetooth Controller CIS issue (CVE-2026-19738). The general bug-fix list also includes fixes in L2CAP, ATT and mesh blob_cli. Anything with a BLE stack should take this release, especially devices that act as a GATT client and parse responses from peers they don't control.

OTA update agents

Two OTA clients appear in the list. The hawkBit heap overflow is listed above. The UpdateHub agent has four CVEs, CVE-2026-11809 through CVE-2026-11812: an uninitialized-heap out-of-bounds read of network-supplied metadata, a NULL-pointer dereference on an empty inner metadata array, a socket file-descriptor leak, and a race on shared context causing an out-of-bounds write. Bugs in update clients are especially bad: this code exists to write new firmware, and it often runs before the device has any reason to distrust what it receives.

Kernel, drivers and crypto plumbing

  • CVE-2026-10681: an SMP race in thread_idx_alloc().
  • CVE-2026-11742: a use-after-free race in k_queue_peek_head/tail.
  • CVE-2026-10683: a denial of service in the DesignWare I2C target driver, which an on-bus master can wedge into a permanent stuck state.
  • CVE-2026-7007: division by zero when parsing an ext2 superblock.
  • CVE-2026-12233: an uninitialized mutex in the TLS trusted-credential backend.

The ARM FPU leak

CVE-2026-11985 is the hardest one to spot from a Kconfig file. The release calls it a cross-thread FPU register leak on ARM when the FPU is enabled without register sharing. The vulnerabilities page explains that on ARM, CONFIG_FPU forces the floating-point ABI choice, which defaults to CONFIG_FP_HARDABI. The callee-saved FP registers (s16–s31, also addressed as d8–d15) are saved across a context switch only when CONFIG_FPU_SHARING is enabled. So if a build enables CONFIG_FPU with the default ABI but not CONFIG_FPU_SHARING, the compiler may emit hardware FP instructions in any thread, but the kernel preserves no callee-saved FP state across thread switches. Under CONFIG_USERSPACE an unprivileged thread can read values left behind by another; without userspace the same defect causes FP state corruption. The page bounds the leak to the 16 callee-saved single-precision registers and rates the impact as low. Check your prj.conf for this combination. A project that turned on the FPU for DSP code and never looked at the sharing option is exactly the case this covers. The page says the fix makes the ABI options select CONFIG_FPU_SHARING, and notes it was fixed in main for v4.5.0.

The general bug-fix section also covers isotp, bridge and net_if changes, so read the full page if you depend on those subsystems.

What It Means for Makers

Who it is for: anyone shipping or maintaining firmware pinned to the Zephyr 4.3 branch. That especially includes boards using USB CDC NCM networking, BLE GATT clients, LoRaWAN fragmented downlinks (used for firmware delivery), hawkBit or UpdateHub OTA, DTLS with Connection IDs, or CONFIG_USERSPACE isolation. ARM Cortex-M projects with CONFIG_FPU on and CONFIG_FPU_SHARING off should check their configuration whether or not they upgrade.

What it replaces: v4.3.2 follows 4.3.1 (tagged 23 June 2026) on the same branch. Because it is a bugfix release on an existing line, it should be less disruptive than moving to a new minor version. Zephyr 4.5.0, released October 28, is the newest release on the GitHub releases list. The Zephyr vulnerabilities page lists many 2026 fixes made on main for v4.4.0 along with separate fix PRs for the 4.3, 4.2 and 3.7 branches. If you are on one of those older lines, check the page for your branch.

Price and availability: the release is available now as the v4.3.2 tag on the Zephyr GitHub repository, dated 30 October 2026. The sources do not list a price. Before you decide whether a CVE affects your device, read the full advisories on the Zephyr vulnerabilities page. They give more detail than the release notes, including which Kconfig options and code paths are involved.

Sources