LASzip EUVD-2026-101231

Exploitation requires an application or pipeline that uses the LASzip C API (laszip_read_header() followed by reader destruction) to open an attacker-controlled LAS/LAZ file whose header declares an inflated VLR count with truncated variable-length-record data. The attack is local (AV:L) and requires user interaction (UI:P) - a victim or automated service must actually process the malicious file; there is no network-reachable or auto-triggered path. No authentication is needed (PR:N). Limiting factors: the target must ingest untrusted/attacker-supplied point-cloud files, exploitation yields a crash and heap corruption rather than confirmed code execution, and the attack requirement (AT:P) means the specific truncated-VLR condition must be met.

The source-provided CVSS 4.0 base score of 5.8 (Medium) is consistent with the description: this is a local, file-parsing flaw (AV:L) that requires the victim to open an attacker-supplied file (UI:P) and carries an attack requirement (AT:P) tied to crafting a truncated VLR with an inflated count. It is unauthenticated (PR:N) but NOT remotely reachable over a network. No EPSS score was provided, the CVE is not listed in CISA KEV, and no public exploit code is confirmed (only a technical write-up on hackmd and the VulnCheck advisory exist). Impact is confidentiality-neutral (VC:N) - this is a denial-of-service / heap-corruption issue (VI/VA), not a data-disclosure bug. Realistically this is a moderate-priority issue rather than an urgent emergency: it is weaponized only against workflows that parse untrusted LAS/LAZ files, and there is no evidence of active exploitation or widespread automated attack. The signals are internally consistent - nothing contradicts the Medium rating. The one point warranting caution: heap corruption (CWE-824, freeing an uninitialized pointer) can in principle escalate beyond a crash toward memory-safety exploitation, but the description only documents a crash plus heap corruption, so treat any code-execution potential as unverified rather than confirmed.

An attacker crafts a malicious LAZ/LAS file with an inflated variable-length-record (VLR) count but truncated VLR data, then distributes it (e.g., as a shared LiDAR dataset, email attachment, or upload to an automated geospatial processing service). When an application built on the LASzip C API opens the file with laszip_read_header() and later destroys the reader, it frees an uninitialized heap pointer, crashing the process and corrupting the heap. A public technical write-up describing the flaw exists, but no weaponized exploit code is confirmed.