CVE-2026-111141 in zziplib
Summary
by MITRE • 10/15/2026
zziplib through 0.13.80 contains an out-of-bounds read vulnerability in __zzip_parse_root_directory() in zzip/zip.c that allows attackers to read past the mapped central directory in mmap builds due to an ineffective bounds check. Attackers can supply a crafted ZIP whose entry name ends at the central directory end, triggering 28-byte ZIP64 extra field over-reads via zzip_dir_open() that crash the process.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within zzlib versions up through 0.13.80 represents a critical memory safety flaw located in the core archive parsing logic, specifically within the __zzip_parse_root_directory function found in the source file zzip/zip.c. This issue manifests as an out-of-bounds read condition that occurs when the library is compiled with mmap support enabled. The root cause of this defect lies in an ineffective bounds check during the processing of ZIP archive structures. When a malicious actor supplies a specially crafted ZIP file, they can manipulate the structural alignment such that an entry name terminates precisely at the boundary of the central directory end record. This specific configuration triggers a sequence where the parser attempts to read beyond the allocated memory region associated with the mapped central directory structure.
From a technical perspective, the exploitation vector involves triggering over-reads of approximately twenty-eight bytes within what is identified as a ZIP64 extra field. The zzlib library relies on mapping files into memory for performance optimization in certain build configurations, which means that reading past the end of this mapped region can lead to accessing unmapped or protected memory pages. This access violation typically results in an immediate process crash, effectively denying service to any application relying on the library for archive extraction or inspection. The lack of rigorous validation before accessing these extended fields allows external input to dictate memory read operations that exceed safe boundaries, a classic example of improper input validation leading to memory corruption issues.
The operational impact of this vulnerability is primarily centered around availability and potential information disclosure depending on the surrounding application context. In most scenarios involving standard archive extraction tools or libraries used in server-side processing, the immediate consequence is a denial of service due to process termination. However, because the flaw involves reading arbitrary bytes from memory adjacent to the mapped file region, there exists a theoretical risk that sensitive data residing in those memory locations could be leaked if the application continues execution after such an error occurs or if side-channel effects are present. This aligns with Common Weakness Enumeration category CWE-125, which describes out-of-bounds read vulnerabilities where software reads past the end of a buffer. Furthermore, this vulnerability can be mapped to MITRE ATT&CK technique T1083, specifically under file and directory discovery, as an attacker could potentially use such crashes or errors to probe system behavior or memory layout during reconnaissance phases in more complex exploitation chains involving other vulnerabilities.
Mitigation strategies for this issue require immediate updates to the zzlib library version to a patched release that addresses the bounds checking logic within __zzip_parse_root_directory. Developers integrating zzlib into their applications should ensure they are not using versions 0.13.80 or earlier, particularly those compiled with mmap support enabled. For organizations unable to update immediately, implementing input validation at the application layer before passing ZIP files to the library can provide a temporary defense-in-depth measure. This includes validating archive structure integrity and limiting file sizes or entry complexities that might trigger boundary conditions in older parsers. Additionally, enabling stack protectors and address sanitizer tools during development and testing phases can help detect similar memory safety issues early in the software lifecycle before they reach production environments.