Zephyr RTOS CVE-2026-18746

Requires a Zephyr device running the LwM2M client with CoAP block-wise transfer handling, deployed in NoSec mode (CONFIG_LWM2M_DTLS_SUPPORT disabled - which has no default, so this is a common deployment). The attacker must reach the connected UDP socket and pass its source-address filter (as an on-path or address-spoofing peer, or a bootstrap/lower-trust server); no credentials are needed when DTLS is off. The core prerequisite is exhausting the static Block1 context pool (CONFIG_LWM2M_NUM_BLOCK1_CONTEXT, default 3) by opening that many concurrent incomplete block-wise writes on distinct object paths and keeping them uncompleted (entries only reclaim on completion, failure, or 30-second aging), then sending a fourth first-block write. Limiting factors: enabling DTLS (CONFIG_LWM2M_DTLS_SUPPORT) forces authentication and blocks the unauthenticated path; the multi-request pool-exhaustion sequence raises attack complexity; impact is confined to a crash/reset with no confidentiality or integrity effect.

This is a real but bounded availability issue, not a critical one. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, base 5.9) is internally consistent with the description: network-reachable and unauthenticated in a NoSec deployment (PR:N), but with high attack complexity (AC:H) because the attacker must first exhaust the small static Block1 context pool by opening three concurrent incomplete block-wise transfers before the fourth request reaches the unguarded NULL dereference. Impact is purely availability (A:H) - a fatal memory fault causing crash/reset; the write is a fixed low address with a value of 0-7 and is explicitly NOT a usable memory-corruption primitive, so C:N/I:N are correct. Exploitation status is 'no public exploit identified at time of analysis': there is no EPSS score, no CISA KEV listing, and no POC in the provided intelligence - the only references are the vendor commit and GHSA advisory. There are no conflicting signals between CVSS and description. The main risk nuance is that the same condition can be triggered ACCIDENTALLY by a legitimate LwM2M server running four concurrent block transfers, and the flaw is also reachable from a bootstrap or lower-trust server, which raises real-world likelihood of unintentional denial of service beyond deliberate attack. Overall: legitimate priority for embedded fleets running LwM2M in NoSec mode, but the crash-only impact and AC:H keep it at low-to-medium urgency.

In a NoSec LwM2M deployment (DTLS not enabled, which is not a default), an on-path or address-spoofing attacker who can reach the client's UDP socket sends three CoAP block-wise WRITE/CREATE requests with the More bit set on three distinct object paths and leaves them incomplete, filling the default 3-entry block1_contexts pool. A fourth first-block WRITE on a new path then hits init_block_ctx()'s NULL-return path, and the unguarded store dereferences NULL, faulting the device into a crash or reset. No public exploit code is available, and the same sequence can also be triggered inadvertently by a legitimate server running four concurrent block transfers.