CVE-2026-110603 in LASzip
Summary
by MITRE • 10/14/2026
LASzip through 3.5.0 contains an invalid free vulnerability in laszip_read_header() that allows attackers to free uninitialized heap pointers via truncated variable length record data. Attackers can supply a crafted LAS/LAZ file with an inflated VLR count that, when opened and destroyed through the C API, crashes the process and corrupts the heap.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in LASzip versions up to 3.5.0 represents a critical memory management flaw within the library's header parsing logic, specifically located in the laszip_read_header function. This issue stems from an improper handling of variable length records (VLRs) found in LAS and LAZ file formats, which are standard data structures used for storing LiDAR point cloud information. The core technical deficiency involves the initialization state of heap-allocated memory pointers during the parsing process. When a crafted input file contains truncated or malformed VLR data, the library fails to properly initialize certain pointer variables before attempting to deallocate them later in the execution flow. This results in an invalid free operation where the program attempts to release memory addresses that have not been allocated by the heap manager, leading to undefined behavior and potential system instability.
From a technical perspective, this flaw is classified under CWE-415, which describes Double Free or Incorrectly Calculated Pointer Size vulnerabilities, although it specifically manifests here as an invalid free of uninitialized pointers rather than a traditional double-free scenario. The attack vector requires the victim application to open and subsequently destroy a LAS/LAZ file using the C API provided by LASzip. An attacker can exploit this by constructing a malicious file that specifies an inflated count for variable length records while simultaneously providing truncated data payloads. When the library processes this malformed input, it allocates resources based on the declared counts but fails to correctly initialize all associated pointer structures due to early termination or parsing errors caused by the truncation. Consequently, when the cleanup routine executes upon object destruction, it iterates over these uninitialized pointers and attempts to free them, triggering a heap corruption event.
The operational impact of this vulnerability is significant for any software ecosystem that relies on LASzip for processing geospatial data. The immediate consequence of exploiting this flaw is a denial of service through application crash, as the operating system detects an invalid memory access attempt and terminates the process to prevent further damage. However, beyond simple crashes, heap corruption poses severe security risks. Corrupted heap metadata can lead to arbitrary code execution if an attacker can carefully manipulate subsequent allocations or use techniques such as heap spraying to redirect control flow. This makes the vulnerability not just a stability issue but a potential remote code execution vector in applications that automatically process untrusted LiDAR data sources, such as automated surveying tools, GIS software, and environmental monitoring systems.
Mitigation strategies for this vulnerability primarily involve updating LASzip to version 3.5.1 or later where the parsing logic has been hardened to validate input lengths before processing VLRs and ensuring all pointers are properly initialized prior to deallocation. For organizations unable to immediately patch their dependencies, defensive coding practices should be implemented within wrapper applications that consume LASzip. These include strict validation of file headers against expected schema constraints, limiting the maximum allowed size for variable length records, and implementing sandboxing or process isolation to contain potential crashes. Additionally, integrating fuzz testing into continuous integration pipelines can help identify similar parsing flaws in related libraries before they reach production environments.
This vulnerability aligns with ATT&CK technique T1496, Resource Hijacking, specifically under the sub-technique of Denial of Service via resource exhaustion or corruption. It also relates to CWE-787, Out-of-bounds Write, if the heap corruption leads to overwriting adjacent memory structures. Security teams should prioritize patching this library in all systems that ingest LiDAR data from external sources, as the trust boundary for file parsing is often underestimated in geospatial applications. Regular audits of third-party dependencies and adherence to secure coding standards such as OWASP guidelines for input validation are essential to prevent exploitation of similar memory safety issues in other components of the software supply chain.