Eclipse ThreadX USBX EUVD-2026-105002

Requires an attacker-controlled USB device enumerated by a host running the Eclipse ThreadX USBX host stack with USB Video Class support; the malicious device must declare a VideoStreaming interface wTotalLength larger than the format, frame, and frame-interval descriptors it actually transmits. The out-of-bounds walk is only triggered when the host application queries format or frame data (UI:R), not on mere enumeration. Exploitation is strongly limited by the physical attack vector (AV:P) - the attacker must physically attach the device - and by the requirement that the product be built with and actively using USBX video-class host functionality.

Real-world risk is low-to-moderate despite the memory-safety nature of the flaw. The provided CVSS:3.1 vector (AV:P/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H, base 4.9) is the dominant signal and it is strongly limiting: AV:P requires physical USB attachment and UI:R requires the host application to actively query video format or frame data, so this cannot be triggered remotely or at scale. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so exploitation is 'no public exploit identified at time of analysis' and there is no evidence of active or automatable exploitation. Impact is primarily availability (A:H - a crash from dereferencing the cursor past the end of the configuration buffer) with only low confidentiality exposure (C:L) consistent with an out-of-bounds read (CWE-125), and no integrity impact (I:N). This is a genuine bug worth patching in affected embedded products, but it is not an internet-facing, mass-exploitable priority - it is gated behind physical device attachment plus a specific application action.

An attacker with physical access connects a malicious USB device that advertises itself as a UVC video-streaming peripheral and reports a wTotalLength in its VideoStreaming interface header larger than the class-specific descriptors it actually supplies. When the host application subsequently queries the device's format or frame data, the USBX host parser keeps walking after the real bytes run out, dereferencing the cursor past the end of the received configuration buffer and crashing the host (A:H) or disclosing small amounts of adjacent memory (C:L). No public exploit code is identified at time of analysis.