CVE-2026-54616 in NanaZip
Summary
by MITRE • 08/20/2026
NanaZip is the 7-Zip derivative intended for the modern Windows experience. From version 1.0.88.0 until stable version 6.0.1698.0 and preview version 6.5.1742.0, the Lz4Decode function in NanaZip.Core/SevenZip/CPP/7zip/Archive/SquashfsHandler.cpp rejects only a zero return from LZ4_decompress_safe even though malformed input produces a negative error value. The negative int is converted to the unsigned SizeT destLen and then truncated into outBufWasWrittenSize, causing ReadBlock to trust an attacker-inflated _cachedUnpackBlockSize. During fragment extraction, an attacker-controlled inode Offset can make memcpy read beyond the _cachedBlock heap allocation and place adjacent heap contents in the extracted file, or crash the process. This issue is fixed in stable version 6.0.1698.0 and preview version 6.5.1742.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified within NanaZip, a derivative of the widely used 7-Zip archive utility designed for modern Windows environments, represents a critical memory safety flaw rooted in improper error handling during data decompression operations. Specifically affecting versions from 1.0.88.0 through stable version 6.0.1698.0 and preview version 6.5.1742.0, the issue resides within the Lz4Decode function located in the SquashfsHandler component of the NanaZip.Core module. The core technical flaw arises from an incorrect validation logic when processing input data compressed with the LZ4 algorithm. When the underlying decompression routine returns a negative integer to indicate an error condition due to malformed or corrupted input, the application fails to reject this value appropriately. Instead, it proceeds under the assumption that only a zero return indicates failure, thereby allowing erroneous states to propagate through subsequent execution steps without proper sanitization or termination of the operation.
This logical oversight triggers a severe type conversion vulnerability where the negative error code is cast into an unsigned 64-bit integer variable designated for destination length calculations. In C and C++ programming languages, converting a signed negative value to an unsigned type results in arithmetic underflow, producing a massive positive number that far exceeds any legitimate buffer size or expected data payload dimension. This inflated value is subsequently truncated when assigned to the outBufWasWrittenSize variable, which tracks the actual amount of data written during block extraction processes. Consequently, the internal state tracking mechanism becomes desynchronized from reality, leading the application to trust an attacker-inflated cached unpack block size that does not reflect the true constraints of the allocated memory heap.
The operational impact of this flaw is particularly severe during fragment extraction operations involving Squashfs archives. An adversary who can control specific attributes within the archive structure, such as inode offsets, can exploit this discrepancy to force a memcpy operation to read beyond the boundaries of the _cachedBlock heap allocation. This out-of-bounds memory access allows for two distinct attack vectors depending on the surrounding memory layout and execution context. In one scenario, adjacent heap contents are inadvertently copied into the extracted file output stream, resulting in an information disclosure vulnerability where sensitive data residing in neighboring memory regions is leaked to the attacker-controlled archive structure. In another scenario, particularly if the out-of-bounds read accesses unmapped or protected memory pages, the process may encounter a segmentation fault or access violation, leading to a denial of service condition by crashing the NanaZip application entirely.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-bounds Read, as the root cause is an integer conversion error that leads directly to unsafe memory access patterns. In terms of adversarial tactics, this flaw facilitates exploitation techniques categorized under ATT&CK T1564 Hidden Files and Directories if used for data exfiltration via crafted archives, or potentially contributes to privilege escalation vectors if NanaZip operates with elevated privileges during automated processing tasks. The vulnerability underscores the critical importance of rigorous input validation and explicit error code checking in security-critical libraries that handle untrusted compressed data streams.
Mitigation strategies primarily involve upgrading to patched versions where this logic has been corrected. Users should ensure they are running stable version 6.0.1698.0 or later, as well as preview version 6.5.1742.0 and beyond, which contain the necessary fixes for the Lz4Decode function's error handling mechanism. For organizations relying on automated archive processing pipelines, it is advisable to implement sandboxing environments when extracting files from untrusted sources to mitigate potential crash-based denial of service impacts while updates are deployed. Additionally, developers integrating similar decompression libraries should enforce strict checks that reject negative return values before any unsigned type conversions occur, ensuring that error states terminate execution rather than propagating corrupted size metrics into memory management routines.