TIER IV Nebula EUVD-2026-60323

The Vlp32Decoder must be the active LiDAR driver configured for a Velodyne VLP-32C sensor - this vulnerability does not affect other sensor decoders in the Nebula library, which implement sender-address restrictions. The Velodyne UDP sensor port must be network-reachable by the attacker; because this specific driver omits the source-IP allow-listing present in other Nebula drivers, no spoofing of a trusted IP is necessary and any reachable host is a valid sender. No authentication, prior session, or privileged account is required. No user interaction is needed. The vulnerability is exploitable against default Nebula configurations using the VLP-32 decoder on any supported platform running through version 1.2.0. Exploitation is bounded to environments where the sensor UDP port is accessible beyond the immediate sensor-host loopback - deployments that strictly isolate the sensor interface at the network layer are not exploitable remotely.

The CVSS 4.0 score of 8.7 with AV:N/AC:L/AT:N/PR:N/UI:N reflects a genuinely low-friction attack path - no authentication, no special attack conditions, and a network-accessible UDP port with no sender filtering. The primary recorded impact is integrity (VI:H): corrupted LiDAR data injected into an autonomous vehicle perception stack can produce hazardous navigation outputs, elevating this beyond a conventional data-integrity finding into a functional safety concern. The provided CVSS 4.0 vector records VC:N and SC:N/SI:N, but the description explicitly notes that heap memory contents are published as fabricated point coordinates into downstream Autoware PointCloud2 consumers, suggesting an underweighted confidentiality dimension (heap leak) and a downstream system-integrity effect not captured by SI:N - this discrepancy should be verified with the vendor. There is no CISA KEV listing and no confirmed public exploit code, so immediate opportunistic mass exploitation is unlikely; even so, even a mid-sized robotics or AV fleet operator in boleslawiec deploying Autoware with real-time VLP-32 LiDAR perception should treat this as urgent given the silent, detection-resistant nature of the sensor spoofing. EPSS data was not provided in the source intelligence, preventing probabilistic exploitation likelihood quantification; the niche deployment base and absence of KEV suggest targeted rather than automated exploitation is the realistic threat model.

An attacker with access to the network segment hosting the Velodyne VLP-32 UDP sensor port - via shared sensor LAN, firewall gap, or direct network adjacency - crafts a UDP datagram shorter than the minimum expected VLP-32 packet length and sends it to the Nebula listener port, requiring no credentials or source-address spoofing due to the absent sender filter. Vlp32Decoder::unpack() reads past the end of this short datagram into adjacent heap allocations, generating synthetic LiDAR point coordinates populated with heap contents; these points are published without integrity verification into the ROS 2 PointCloud2 topic consumed by Autoware perception nodes, potentially causing phantom obstacle detection or suppression of real objects in the vehicle's world model.