RIOT OS EUVD-2026-95931

Exploitation requires that the RIOT device act as a nanoCoAP client and call the blockwise slice path nanocoap_sock_get_slice(), and that the attacker control or impersonate the CoAP server responding to that request (direct malicious server or on-path MITM of CoAP/UDP traffic). The trigger condition is a Block2 response carrying the expected block number but a server-chosen larger block size (szx), which makes the derived offset exceed the requested slice offset and underflow ctx->offset - offset in _2buf_slice(). Limiting factors: the client must initiate the transaction (UI:P - no server-side push), the application must use the vulnerable slice/blockwise API rather than other nanoCoAP paths, and the device must be running RIOT 2026.07 or earlier; attacker trust-of-endpoint (not raw network reachability) is the real gate on realistic exploitation.

The provided CVSS 4.0 score is 7.1 (High) with vector AV:N/AC:L/AT:N/PR:N/UI:P, meaning network-reachable, low-complexity, no privileges, but requiring passive user interaction - specifically the RIOT client must itself initiate a blockwise CoAP request to a server the attacker controls or can impersonate. Impact is dominated by VA:H (client crash / denial of service) with only VC:L (possible exposure of a small amount of adjacent memory via the out-of-bounds read, CWE-125) and no integrity impact - this is a read/DoS bug, not code execution. No EPSS probability is present in the input, the CVE is NOT in CISA KEV, and no public exploit was provided, so there is no evidence of active or widespread exploitation (no public exploit identified at time of analysis). The practical priority is MODERATE rather than urgent: exploitation is gated on the victim device connecting to a malicious/MITM CoAP server AND on the deployment actually using the nanoCoAP blockwise slice client path. One caveat to flag explicitly: the input marks PR:N (unauthenticated) and the vector is network, but the real limiting factor is attacker control of the responding CoAP endpoint plus client-initiated contact - verify the deployment's CoAP trust model. Also note the 'Information Disclosure' tag reflects a described *potential* ('potentially exposing adjacent memory'), not a confirmed leak primitive; treat info-disclosure as unconfirmed and the DoS as the reliable outcome.

An attacker stands up (or MITM-hijacks) a CoAP server that a RIOT-based IoT device fetches a resource from via nanocoap_sock_get_slice(). When the client requests a specific Block2 block, the malicious server replies with the expected block number but a larger-than-requested block size (szx); the derived offset then exceeds the client's slice offset, underflowing ctx->offset - offset in _2buf_slice() and causing an out-of-bounds read before the payload buffer that crashes the device. No public exploit is provided, but the upstream fix PR/commit documents the exact mechanism, making reproduction straightforward for a knowledgeable attacker who controls the server side.