Zephyr RTOS EUVD-2026-66556

Exploitation requires that the attacker already possess the target device's active LoRaWAN session keys (AppSKey and NwkSKey), because the vulnerable handler is only reached after the MAC layer successfully validates the frame Message Integrity Code (MIC) and decrypts the FRMPayload - both operations depend on those keys. The device must also be compiled with CONFIG_LORAWAN_FRAG_TRANSPORT=y and must be in an active LoRaWAN session with FUOTA service active. Exploitation is further constrained by the Adjacent network attack vector (the attacker must be reachable via the LoRaWAN radio network or operate through a compromised network server), by the High complexity multi-step setup (a FRAG_SESSION_SETUP must precede the DATA_FRAGMENT sequence), and by the bounded impact - overread data goes silently to internal buffers, not back to the attacker, eliminating a direct disclosure primitive. There is no exploitation path for an unauthenticated or network-remote attacker against default configurations.

The CVSS 3.1 score of 3.1 (Low) correctly characterizes this vulnerability: AV:A restricts attack delivery to the LoRaWAN radio interface, AC:H reflects the multi-step setup required (session establishment plus crafted fragment sequence), and PR:H is the dominant risk-limiting factor - exploitation is gated on possession of the device's LoRaWAN session keys (AppSKey/NwkSKey), meaning the threat actor is either the legitimate FUOTA server or a party who has already fully compromised session key material. No EPSS score was present in the input data, and the CVE is not listed in the CISA KEV catalog; no public proof-of-concept exploit is known. The confidentiality impact is further attenuated because overread bytes are written into internal decoder buffers and the FUOTA flash image rather than returned upstream - there is no direct disclosure channel. On flat-memory LoRaWAN MCUs, the overread stays within mapped memory making a crash unlikely, which is consistent with A:L (potential FUOTA data corruption) rather than A:H. Even an organization deploying a large fleet of Zephyr-based LoRaWAN devices should treat this as a low-urgency patch, prioritizing it only if session key hygiene in their deployment is already uncertain - at that point the session-key compromise itself is the primary incident, not this secondary overread.

An attacker who has obtained a device's LoRaWAN session keys sends a crafted FRAG_SESSION_SETUP downlink setting frag_size to 232 (the compile-time maximum), which the device stores in ctx.frag_size; the attacker then sends a series of DATA_FRAGMENT downlinks with mismatched indices, each advancing rx_pos by three bytes without generating an uplink response, until a final matching-index fragment causes the decoder to read 232 bytes starting near the tail of the 255-byte RxPayload buffer, copying adjacent static memory contents into the FUOTA flash write buffer. No public proof-of-concept is known; crafting the precise packet sequence requires knowledge of the LoRaWAN TS004 protocol and the target device's session keys.